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(54) Title: CNC CONTROL SYSTEM 
(57) Abstract 

A machine tool control system that in* 
eludes a controllable, movable tool for shap-/ 
ing a workpiece, a mechanism for receiving 
control instructions describing shaping func- 
tions to be performed on the workpiece, a 
processing unit and memory. The control 
system includes objects defined according to 
an object oriented design. One type of ob- 
ject is a model of a shaping process to be 
performed on a workpiece, including infor- 
mational parameters regarding the physical 
dimensions of the shape resulting from the 
process. The process objects communicate 
through an object oriented messaging system 
to machine objects, which represent physi- 
cal devices present on the CNC machine on 
which the control system operates. The sys- 
tem also includes object oriented motion con- 
trol and exception handler objects, each of 
which may communicate with other object 
via object oriented messages. The control 
system permits easy modifications to the con- 
trol system by persons with limited knowl- 
edge about the entire control system, and is 
readily adaptable to advances in new CNC 
machine tools. ... 
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CNC CONTROL SYSTEM 
Field of the Invention 

This invention relates to computer numeric controlled 
(CNC) machine tools, and in particular, to the control 
5 systems used to operate such machine tools. 
Background of the Invention 

CNC Control Systems The purpose of a CNC machine is 
to use a set of input specifications describing a physical 
object to produce a machined part according to the 

10 specifications. The part is typically formed from solid 
block stock material such as metal, and shaped by various 
machine tools such as drills, mills, lathes, electrostatic 
discharge machines (EDMs) , gauging systems and the like. 
CNC machines are complex and include hundreds of 

15 components. Examples of input devices include keyboards, 
operator consoles, pressure sensitive CRTs, various tools 
and machine sensors, limit switches and network 
interfaces. Output devices include motion. controllers 
that send motion control signals to motors driving axes or 

20 a tool, CRT displays, console status lights and audible 
alarms. Other components include microprocessors, memory, 
disk drives, data buses and wiring harnesses. The 
software executed by the computer processor is a critical 
component of a CNC machine, as it coordinates the 

25 functions of the all the other components of the system. 
In general, CNC software is custom written for the 
particular brand of components a CNC manufacturer or 
system integrator chooses to include in the CNC machine. 
As a result, CNC software is extremely complex, and a 

30 software programmer for a particular CNC machine must be 
intimately familiar with the way virtually every hardware 
component interfaces with the software, and with the 
entire software system itself. 

For example, two representative functions of most CNC 

35 software are the logic and motion control functions 

(collectively referred to herein as the "kernel") . The 
logic control-- function keeps track of the specific — : 
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sequence of steps that must be taken by various movable _ 
hardware components to accomplish a task. For example, 
the steps required to mount a differently sized drill bit 
into the tool holder of a spindle from an automatic tool 
5 changer in a milling application might be: (1) send a 
command to raise the spindle containing the currently 
mounted drill bit so the tool changer will fit underneath 
it, (2) send a command to the tool changer instructing it 
to'move below the spindle, (3) send a command to the 
10 spindle instructing it to release the currently mounted 
drill bit, (4) wait for a signal from the spindle 
indicating that the drill bit has been released, (5) send 
a command to the tool changer instructing it to move to 
rotate clockwise 30 degrees to position the new drill bit 
15 below the spindle, (6) interrogate the tool changer to 
confirm that the tool changer has successfully executed 
the rotation command, (7) send a command to the spindle 
commanding it to engage the new drill bit underneath it in 
the tool changer, and (8) send a command to the tool 
changer instructing it move away from the spindle and work 
area. Given the hundreds of moving, controllable parts in 
a CNC machine tool, the logic control function is much 
more complex than the above simplified example 
illustrates. 

The motion control function of the software receives 
commands describing how a particular axis or motor should 
be moved. For example, in the above example for logic 
control , the logic control function sent the motion 
control function a command to raise the spindle. The 
motion control function takes this "general" command, 
breaks it down into smaller, discrete movements (i.e. 
controllably move the spindle up 0.001" at a time until it 
has moved up a total of 6 inches),. and sends and receive 
electric signals from precision motors to ensure the 
movement is carried out.. . The motion control function is 
also able to execute more complex, multi-dimensional 
commands, -such. as to move the axes of a milling machine in 
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a pattern so as to cut an ellipse of specified dimensions 
in a workpiece. 

Because the motion control function is the portion of 
the software (except for device drivers) that interacts 
5 most closely with the hardware components that actually 
carry out shaping processes on a workpiece, the motion 
control function also receives information about hardware 
faults from hardware devices. For example, if a hardware 
device is unable to execute an instruction, the motion 
10 control function will receive a notice of the error from 
the hardware (or its associated device driver) . This 
information needs to be communicated back to the other 
portion of the CNC control software responsible for 
requesting the motion control .function to complete the 
15 function the software is currently undertaking, so that 
appropriate action, such as displaying a message on the 
operator CRT, may occur. However, there are usually many 
other portions of the CNC control system software that 
will also need to be informed of the hardware fault. 
20 Moreover, the portions that need to know about the fault 
will vary depending on the exact fault. In past systems, 
the motion control function has been used to keep track of 
which portions of the CNC control system software must be 
notified of which hardware faults. This not only places 
25 an increased burden on the motion control portion of the 
CNC control system software, but also makes this portion 
more difficult to maintain. 



generally designed the entire software system using 
30 structured techniques that analyze what the entire CNC 

machine tool must do (functional decomposition) . This has 
resulted in complex, dif f icult-to-modify software systems. 
For example, software code relating to the user interface 
by which a user describes a part to be machined, can be 
35 found in other portions of the CNC control system 

software, such as the motion controller. . One example is 
that when a motion controller receives -a signal from a 



Computer programmers writing CNC software have 
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machine tool indicating a fault condition (for example, ^ 
when an object in the work area prevents the table from 
moving to a desired location, or a blown fuse) , the motion 
controller might directly display an error message on the 
5 CRT display. Because prior CNC control system software 
generally is not broken down into portions corresponding 
to the discrete, physical components of a CNC machine 
tool, a change in one portion of the software is difficult 
to make and frequently requires changes to other portions 

10 of the software. 

Another example illustrating this problem occurs when 
a user, system integrator or even machine tool 
manufacturer wishes to add a new hardware component to the 
machine tool. For example, it may be desirable to replace 
15 an AC induction motor with a DC brushless motor from a 
different manufacturer. The new motor will likely use a 
different communications protocol and have different 
tolerance specifications and operating limits. Therefore, 
the motion control software will need to be modified to be 
able to communicate with the new motor using its 
communications protocol. The user interface will also 
need to be modified so that the user may specify the 
improved tolerance parameters. However, with past CNC 
software, these changes will have a ripple. effect 
throughout the entire software system, greatly increasing 
the time required ..to develop a new software system capable 
of using the new motor. Many of the additional, revisions , 
are caused by the fact ^that the data the software needs to 
access is dispersed throughout the entire software system. 
For example, to add a new software function, the software 
may need to know, what tool is presently in the spindle, 
the speed the .spindle is .rotating, the coordinates of the 
axes (location of the table) , the readings of a thermal 
sensor , information . about forces being exerted on the 
35 cutting spindle, and the stage (or step) of processing the 
workpiece, is. currently in. : In past, CNC. systems,;. this : 
information would .likely .be diffused throughout various 
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software modules, and the way these data elements interact 
is either too complex to discern (except to the original 
software author) , or proprietary. 

These problems with CNC control systems have led to 
5 several other problems throughout the industry. There is 
a long lead time for system integrators or CNC machine 
tool manufacturers to be able to incorporate new hardware 
components into existing systems. This problem applies 
not only to new CNC machine designs, but also to efforts 
10 to add improved or additional components to an existing 
CNC machine tool, or to retrofit an existing machine tool 
with CNC capabilities. Another problem is that of 
scalability. Because CNC control software is usually 
written for use in accordance with an anticipated 
15 collection of hardware components, the same software can 
not be easily adapted for use in connection with other 
hardware components. In other words, CNC software is 
generally not "scalable," meaning that the software used 
to operate sophisticated, high-end CNC machines can not 
20 also be used to operate "bare-bones," low-end CNC machine 
tools. As a result, CNC manufacturers "reinvent" software 
having the same functionality merely because it designed 
to work in a CNC having different hardware components. 
Programmers for CNC control systems can also be 
25 required to "reinvent" software components not just in 
response to new hardware, but also in response to new 
standards for inputting descriptions of parts to be formed 
by the CNC machine. The earliest CNC machines accepted 
part definitions through punched paper tape. Subsequent 
30 CNC machines (such as that disclosed in U.S. patent no. 
4,477,754) interrogated a machine operator through a 
series of questions to obtain instructions about how to 
create a desired part. More recently, several standard 
data file formats have emerged for describing parts to be 
35 machined, such as the HURCO conversational or RS-274D M&G 
code programs. In the past "part program, interpreter" 
modules of CNC control system' programs/ each module used 
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for accepting a part definition in a different format, „ 
would generally have to access, as described above 
various data elements and software routines dxf fused 
throughout the CNC control system software. Again, each 
5 different input format has resulted in a unique part 

program interpreter software program, and these programs 
all include much common, and therefore needlessly 
duplicative, functionality. 

g^ier^ed software Most existing programming 
10 languages provide "sequential" instructions for a 

processor to implement. These languages have previously 
been used to implement CNC control systems. However, 
computers are often utilized for modeling systems of 
interactive components in order to determine sequences of 
15 actions such systems would perform under various 

conditions. For example, a programmer may wish to program 
a computer to mimic the manner in which some particular 
digital logic network responds to a particular input 
stimulus. When the programmer doesn't : know beforehand ' 
20 what sequence of steps the logic network would carry out 
in response to the stimulus, but only knows how each 
individual component changes its outputs in response to a 
change to Vits inputs, the programmer often finds it 
difficult" to utilize- sequentially organized instructions 
25 to program a computer to model the behavior of the system. 

in contrast to sequentially organized software, 
"object-oriented" software is organized into "objects", 
each comprising a block of computer instructions 
describing various procedures ("methods") to be performed 

30 in response to "messages" sent to the object. Such 
operations include, for example, the manipulation of 
variables and the transmission of one or more messages to 
other objects. Messages are sent and received between 
objects having certain functions and knowledge to carry, 

35 out processes.. When one of the objects .receives a-.- 

messaged -the object carries out an operation (a message • 
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procedure) corresponding to the message and, if necessary, 
returns a result of the operation . Each object has a 
region where internal states (instance variables) of the 
object itself are stored and where the other objects are 
5 not allowed to access. The objects comprise concept 

objects that represent concepts and instance objects that 
represent instances of the concept objects. The concepts 
are clearly separated from the instances. One feature of 
the object-oriented system is inheritance. With respect 
10 to a certain concept object, there is defined an upper 
concept object that has a concept more abstract than a 
concept held by the certain concept object, and the 
certain object can inherit the functions (message 
procedures) and knowledge (instance variables) of the 
15 upper concept object to utilize them. For example, a 
concept object "circle" may inherit functions and 
knowledge from its upper concept object "shape." 

A programmer "programs" in an object-oriented 
programming language by writing individual blocks of code 
20 each of which creates an object by defining its methods. 
A collection of such objects adapted to communicate with 
one another by means of messages comprises an 
object-oriented program. Object-oriented computer 
programming facilitates the modeling of interactive 
25 systems in that each component of the system can be 

modeled with an object, the behavior of each component 
being simulated by the methods of its corresponding 
object, and the interactions between components being 
simulated by messages transmitted between objects. 
30 An operator may stimulate a collection of 

interrelated objects comprising an object-oriented program 
by sending a message to one of the objects. A method of 
the object receiving the message may cause the object to 
respond, carrying out predetermined functions which may 
35 include sending messages to one or more other objects. 
The other objects may in turn ' carry out additional 
functions in response to the messages they receive, 
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including sending still more messages. In this manner, _ 
sequences of message and response may continue 
indefinitely or may come to an end when all messages have 
been responded to and no new messages are being sent. 
When modeling systems utilizing an object-oriented 
language, a programmer need only think in terms of how 
each component of a modeled system responds to a stimulus 
and not in terms of the sequence of operations to be 
performed in response to some stimulus. Such sequence of 
operations naturally flows out of the interactions between 
the objects in response to the stimulus and need not be 
preordained by the programmer. 

Although object-oriented programming makes simulation 
of systems of interrelated components more intuitive, the 
operation of an object-oriented program is often difficult 
to understand because the sequence of operations carried 
out by an object-oriented program is usually not 
immediately apparent from a software listing as in the 
case for sequentially organized programs. Nor is it easy 
to determine how an object-oriented program works through 
observation of the readily apparent manifestations of its 
operation. Most of the operations carried out by a 
computer in response to a program are -invisible" to an 
observer since only a relatively few steps in a program 
typically produce an observable computer output. 

Object-oriented analysis and design methods permit 
reuse of system, analysis and requirements from other , 
products in the same family. Object-oriented software 
design means that software components are created from 
30 data and functions and are organized into objects. An 

object is an abstraction of something in the real world, 
reflecting the capabilities of a system to keep 
information about it, interact with it, or both. It is,, 
therefore, an encapsulation , of attribute values and their 
exclusive services.. An object's attributes, describe the 
object, but not how it works. The object's services are 
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instructions, programs, procedures, or actions that 
describe what the object will do when something happens. 

As described above, objects are grouped into classes. 
A class includes a description of how to create new 
5 objects in the class and establishes the basic variables 
that are common to all of its objects. New objects inherit 
these common characteristics from the parent class. This 
feature allows the software engineer to build on existing 
design and code by creating more specific objects from the 
10 easily reused code in the general class. For example, a 
software engineer can use a general class of 
characteristics for a 'device 1 to create a model of a more 
specific device such as a spindle. Object-oriented 
analysis and design explicitly represent commonality in 
15 the system's objects and use inheritance to identify and 
capitalize on commonality of attributes and services. The 
system may only access data through the services, if at 
all. Services hide an object's data and send messages to 
perform operations. This isolates dependency on a 
20 particular data structure thus permitting new features to 
be added without changing the arrangement of the original 
objects. This structure protects the data % from the damage 
that commonly occurs during changes in monolithic, 
proprietary systems. 

Objects of the Invention 

One object of the invention is to provide a ' CNC 
machine tool control system that utilizes an object 
oriented program in which objects exchange object oriented 
messages. 

Another object of the invention is to provide a CNC 
machine tool control system that is scalable such that it 
may be used for either high end or low end CNC machine^ 
tools . 

Another object of the invention is" to provide a CNC 
machine tool control that is easily modifiable, in which 
previously written software can be* reused r ; and in which 
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new objects can be added which inherit or comprise 
compositions of previously defined objects. 

Another object of the invention is to provide a CNC 
aachine tool control system in which new processes may be 
added by a programmer without requiring the programmer to 
know details of how particular hardware components carry 
out specific workpiece shaping processes. 
PT -j Q -F nocrrintion r>f the Drawings 

Fig. 1 is a schematic diagram of the hardware 
components of a CNC machine tool system on which the 
control system of the present invention may operate. 

Fig. 2 is a schematic diagram of the types of 
software classes included in a CNC control system, and 
several representative types qf object-oriented objects 
15 within several of these classes. 
summary o * Tnvention 

The control system of the present invention provides 
a real-time CNC software system that isolates system 
responsibilities into classes that permit a CNC 
20 manufacturer or system integrator to manage complexity and 
change. The control system allows different systems to be 
created from the same model and future, as yet unimagined, 
technological advances can be incorporated without 
redesigning or making massive changes. 

The system utilizes an object-oriented software 
environment. A first class of object types is provided 
for processes (such as drilling, reaming, milling) to be 
carried out by machine tool components (the Process 
Class) . Some processes objects may inherit 
characteristics of other objects in the Process class. 
For example, a "hole" object may have characteristics such 
as a depth and diameter, which can be inherited by other 
process objects, such as a drill, ream or bore process 
object. A second class of object types of is provided 
which represent instances of machine, tool components , such 
as a table (axes), a spindle, tool changer or operator 
console! Again, - some objects may inherit attributes of 
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other objects. For example, an axis group, namely an 
object for simultaneously controlling multiple axes to 
shape complex three-dimensional objects, may be inherit 
attributes of a single axis object. Other objects may be 
5 composite objects of other tool objects. For example a 
tool changer may be a composite object of a collection of 
different milling bits which may be held in the tool 
changer (in addition to having its own attributes) . 

Most importantly, during execution of the software 
10 component of the control system, the objects transmit 
messages to each other. For example a drill process 
object can be defined to hold all the information needed 
to define a drilling process, and this information may be 
sent in a message to an Machine Class spindle object (to 
15 move the spindle down and form the hole) and to an axis 
group object (to position the workpiece in the proper 
location) . However, the portion of the software which 
defines the drilling process does not need to access 
information regarding how the actual machine tool 
20 component carries out its task, or how the motion control 
module controls the machine components. Therefore, in a 
software, implementation, the same process object can be 
used in virtually any CNC machine, without undue regard to 
its manufacturer or specific hardware components. 
25 Moreover, the object oriented messages through which 

various objects communicate provide a standard interface 
for adding additional functionality to a CNC machine tool 
control system. 

For example, the primary purpose of a user interface 
30 is to collect information about a series of machining 

processes to be performed. Once the basic information is 
collected, the user interface can execute the processes 
by: (1) calling a process object with data about a new 
process to thereby create the object; (2) repeat step (1) 
35 for each process; and (3) sequentially sending a message 
to each defined object telling it to execute itself. 
Thus, the programmer of the user interface may" be ~ * r 
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completely insulated from motion control data required for 
the machine tools to carry out their tasks. 

Because communication between software objects is 
accomplished through messages, software functions can be 

5 more easily distributed among different, simultaneously 

" executing tasks. For example, instead of a mot ion control 
module needing to keep track of which task needs 
information regarding a particular hardware fault, 
information regarding a fault may merely be sent to an 
10 exception handler object. This allows the motion control 
module to devote more processing time to its primary task 

. of controlling motion, and permits all error conditions to 
be handled in a uniform manner. Specifically, the 
exception handler may keep a database of which objects 

15 have a need to know about which types of faults, and 

report specific faults only to those objects. Therefore 
in adding a new process or machine component object to the 
system, modification of the motion control module can be 
kept to a minimum as fault conditions may be handled by 

20 the exception handler. 

There are seven basic Classes of software components: 
Device Drivers, Operating System, Platform Services, the 
Kernel, Machine Class objects, Process Class objects, and 
the Operator Class. The Device Drivers class contains the 
25 interfaces to particular hardware such as the hard drive 
floppy drive, serial and parallel, ports, motion board, and 
I/O device. This isolates all hardware interfaces into a 
single class that only needs to be changed when new 
hardware components are added to the existing system 
30 components and need to communicate in a different manner 

with the system. 

The Operating System class is responsible for, 
hardware and software resource management.-. It manages 
memory, timers, and the scheduling of all processes and 
35 tasks. This class. makes it possible to port a. control. 

system in accordance with the present invention system to 
other hardware platforms. The, Platform, Services, class is 
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responsible for facilitating the execution of tasks such 
as error handling and communication between part program 
interpreters and the lower levels of the system. This 
class simplifies system communications and only requires 
5 change if advances in computer science technology need to 
be incorporated because they improve the efficiency or 
change the management of initialization and message 
handling. The Kernel class handles continuous motion and 
discrete input/output implementation components. This 

10 class forms the stable core of the CNC control system that 
only needs to be changed when performance scaling is 
required. This approach is in sharp contrast to prior CNC 
control systems that require system developers to change 
the Kernel when making changes to the Operator Class 

15 objects, such as the Part Program Interpreter. 

The remaining three classes (Machine , Process, and 
Operator) specifically tailor any system to be a machine 
tool CNC. The Operator and Process classes are the 
"tools" used to communicate clearly to the above hardware- 

20 oriented classes. The Machine class contains the objects 
that makes this communication understandable by the Kernel 
components . 

The Machine class is a collection of objects that 
embody the abstraction of real-world components such as 

25 the tool changer, spindle, or coolant. This class 

describes all generic categories of machine tool devices 
by their basic xrequired characteristics. Operator 
programs usually communicate through the objects in this 
class to the Kernel. The Machine class turns operator 

30 commands such as "change to tool #6" into a message or 

series of messages that can be understood by the Kernel's 
components. New machine tool components can be added to 
the Machine class and existing components can be easily 
modified without making changes to the Kernel. ' 

35 The Process class holds the Process techniques 

(methods) that perform specific common practices on the 
specific type of, -machine (low-end milling machine/ :•. lathe; v< 
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punch press, EDM, gauging system, etc.,. The "*«^» - 
Lis class use multiple Machine class objects and can be 
messed fro* multiple part program interpreter (operator) 
programs. This class usually contains librar.es of canned 
cycles to handle such operations as milling frames, 
tapping, and boring, but it also contains any subroutxne 
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that several different applications need to use 
objects provide easy accessibility to the complex CNC 
features. 

The operator Class (including the Part Program 
interpreter) is an extension of the CNC operator's skills 
and job functions. It also holds the operator programs 
such as part programming and system diagnostics. This 
class makes use of services provided by other classes to 
manage control of the machinery. Using programs at this 
level, the operator can set the system parameters (e.g., 
maximum feedrate) and communicate with the machine tool 
while it is running a part program. Most of the changes 
made to a CNC will be modifications to change what the 
operator can do. These changes usually affect the part, 
programming and part cutting environment and can be made 
at this level with any accompanying techniques changed xn 

the Process class. 

Engineers changing a control system of the present 
invention can easily make changes to the system because 
they do not need to be experts on the entire system to 
make a modification to a single component in a class.^One 
change does not have a ripple effect of change throughout 
the system. Portions of the system that are most Ixkely 
to change such as the user interface and device drivers 
are separated from the Kernel. These components are more 
accessible to. change through PLC programs, customization* 
to the Machine class and addition to or modification of 

operator programs. 

Users of the control system of the present invention 
will have a more stable, design that can be tested for 
completeness .-.The system makes possible the efficient 
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reuse of system analysis, requirements, design, and 
components. The system forces system designers to 
consider all nearly all levels of CNC responsibilities to 
be handled by object-oriented software. In addition, 
5 changes at the Device Driver and Operating System levels 
may incorporate new technologies and at the Operator and 
Process levels will be changed to enhance or scale down 
system features and functionality. The core classes, 
Machine and Kernel, will change infrequently due to the 

10 'all purpose 1 nature of the objects in these two classes. 
The present system uses an open systems, 
object-oriented design approach. This allows users to 
tailor hardware and software to gain the competitive edge. 
The CNC control system allows easy integration of hardware 

15 and software from different suppliers and permits the 

porting of systems to other hardware platforms. Industry 
standard hardware interfaces to simplify assembly and 
maintenance may be used. The system is dynamically 
reconfigurable to easily permit third party development of 

20 software components. The system uses simple, standard 
messages in a message schema. The messages are flexible 
and allow a user to select messages they want to use and 
to alter the messages to meet their needs. The system 
software is scalable to support less expensive and/ or a 

25 full-featured CNC hardware system using the same software 
structure. 

As with data characteristics, services can also be ; 
inherited from the parent class when a new class or object 
is created. Of course, the new class or object may use the 

30 service or create a different version of it. Different 
objects can use identical services. Therefore, a software 
engineer writes the code for the service only once and 
then reuses it after that. The reusability of existing 
object-oriented code makes development and modification 

35 faster because there is less to write : and maintain. 

A diagram of the system of classes of software ; 
component classes is shown in Fig. 2.^ ~ ' y: ■* - ? -'* •«• < 
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The software objects use messages to communicate 
between the components. The class structure si *^* 
system operations and programming by limxtxng the messages 
of interest to each class. For example, the Machxne class 
I e not worry about the Kernel's responsibility such as 
tra vel limits and servo errors. Conversely, the Kernel xs 
not concerned about ownership or devices because the 
Machine class handles that exclusively. Messages sent 
from the Operator and Process classes to the system 
, devices can originate from several sources, xncludxng the 
Part Program Interpreter, the User Interface, Push Buttons 
on the Console or Jog Pendant, or a Sensor Interface 
Applications can communicate with the Kernel through any 
or all of the system classes. . For specific functxons, a 
5 software engineer may bypass a class and connect an 

application directly to the next class or another class 
down. This is accomplished through the standard message 
formats supplied for each. object component in the system. 
The present invention is designed as a series of 
0 autonomous processes rather than a monolithic piece of 
software whioh is typical of embedded software systems. 
As such, a reliable and predictable interface is requxred 
for inter-process communication. The details of the 
communication are. encapsulated into an object referred to 
,5 as the "Transporter" or transport layer. Thxs object xs 
' instigated by each process that intends to communxcate, .. 
with otherprocesses. .Communications to other processes 
are requested by symbolic .name. - • - 

A directory of processes allows for identifyxng the 
30 various processes by symbolic name. A continuously • 
• running process commonly accessible process referred to as 
.•Directory Services" allows all the processes connected 
with the system to register their existence, symbol xc , 
name, and communications, channels. Periodically, 
35 Directory Services interrogates, all the registered ^ 
processes to determine if , they are. still active.. If any 
processes is determined : to. be inactive, -it , is . removed,.from 
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the directory and its communications ports closed. This 
commonly accessible process, having a predetermined 
message protocol, allows the other processes to be 
independently developed and maintained. 
5 A message object is defined as the base class for the 

data to be transmitted between processes. The message 
object contains all of the fundamental information 
necessary for routing information to the other processes. 
Specific derivations of messages are inherited from the 

10 message base class. The contents of these derived 

messages have commonly defined characteristics. Messages 
contain identifiers that inform the recipient process of 
the action to be carried out or the type of information 
being transmitted. The identifiers are designed- as 

15 objects so that the specific details of the ordering of 
data is transparent to third parties. Also, this allows 
for messages to be used as base classes for other message 
classes not yet conceived. 

The messaging approach to inter-process communication 

20 facilitates the independent development of processes for 
interconnection with the system. The Transporter uses 
operating system features to implement the actual message 
transmission. If a different operating system is used as 
the core of the system, the Transporter layer may easily 

25 be exchanged with no - impact on the rest of the software. 
In most conventional systems, moving a system to * another 
computer platform creates significant modification of the 
system software. With the present invention's 
object-oriented, message passing approach, the system may 

30 be more readily moved to another computer environment. 
This message passing approach also limits the impact of 
software flaw because clearly defined interfaces and 
formats play a significant role in building and preserving 
robust software. 

35 The general format for messages (sent between classes 

is set up. as a data structure containing .a- common header 
and the arguments -that are' unique for-each specific — : : 
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message. The header includes several variables that are _ 
common to all messages. The messages are designed to be 
variable length for efficiency. The message type is a 
static identification number which is unique to the class 
5 of message being sent (e.g., a calibration message). The 
transaction number, unique for each specific message 
transmission, is assigned at the time the message is sent 
and is used to match responses to the messages. 

The response message is set up so that it uses the 
10 request message's ID and transaction field, and the status 
is set to 'received' or 'completed' or 'denied' as 
required. -This makes it is clear which request is 
associated with the response. Responses have no arguments 
associated with them. Anything that requires arguments to 
15 be passed is considered to be a. new message. For example, 
the response to an IOSendNode message is an IOInfo message 
with the data field passed. as an argument. A Sample 
message structure is as follows: 

/* The message header includes information about the 

20 message., itself */ > ♦ ■>* • 

typedef. struct lc_header_type 

int msg_size; : ... /* Length of message */ 
int header_size; /* Length. of header info */ 
25 lcmsg message; /*_The enumerated message number */ 
int transaction; , . ,/ * The message transaction number */ 

enum type; l]^;- : /* . The ^ e of roessage " (request 1 ' '' : '"[ 
response): .>•..._• rril 

0 = this is a request; (set by sender) 
30 1 = request received -(set by receiver) . 

2 = request completed (set by receiver) 

3 = request denied (set by receiver) .. ; - 

4 = no service .available (set .by receiver)., */ 
} lc_header_type; 

35 . There, are three types of messages: actions, ,: 

information blocks (info), and cycles. Actions are system 
messages -that are required to conduct .basic .communication 
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between system components and do not change from one 
machine type to another. Info messages include a block of 
information that was either requested by a system 
component or that is sent relative to a button-event, key- 
5 press or mouse-click for example. Cycles are messages 
that perform customized operations that may change from 
one machine to another. Cycles may be supported by ladder 
logic sequences in the Logic Controller program. In 
addition to using new and existing Cycles, the system 
10 integrator may take advantage of the Softkey and Prompt 
messages in conjunction with ladder logic to form 
customized operations that allow interactive input from 
the operator console. For example, toolchanger calibration 
could be done by invoking a ladder logic sequence which 
15 responds to a specific softkey and then performs the logic 
necessary to do calibration for a particular machine. This 
would require no hard-coded software in the system and 
would be completely configurable by a system integrator 
without the control builder 1 s assistance. 
20 Any Part Program Interpreter (PPI) may be used as 

long as it uses the embodiment's interface. 

Components of the Operator Class may include the 
following: Conversational part program interpreter, NC 
interpreter, Manual mode user interface, Auto mode user 
25 interface, Diagnostics user interface, Program editor for 
conversational programming and Program editor for NC 
programming 

The Process class contains pre-packaged objects using 
multiple class objects. When an application uses packaged 

30 cycles, the operator can specify a type of operation and 
define only the necessary variable information. Then the 
system makes additional calculations to define the 
operation fully. For example, when the operator is 
programming a shaping process such as a hole-making 

35 drilling operation with pecking, the operator simply 

specifies the peck type and depth (thereby defining the X, 
Y and Z dimensions) and the system uses at canned cycle to 
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determine the exact movements of the drill during the . 
pecking process. Another example would be a Billing 
object which represents a milling operation to be used to 
shape a workpiece. The object may further include means 
for defining whether the shape to be milled is to be 
removed from the workpiece or left remaining in ^ e 
vorlcpiece. The object may also include sequencing status 
*eans representative of whether the process def med by the 
object has been performed. In one embodiment, packaged 
cycles are contained in libraries that can be used by 
different operator programs with little or no 
edification. These cycles are pre-programmed, common 
xaachining operations and include drill, tap, peck and 



ream 



The Machine class forms a device-oriented interface 
between the details of the Kernel and the operator 
programs and canned cycles. The Machine class manages the 
complexity of the system by handling the device 
responsibilities between the operator programs and the 
,0 Kernel. The Machine class establishes and ~ it ~^ 
operator programs' connections to the Kernel and handles 
m essages between the applications and Kernel. Each 
application has a copy of the Machine class included in 
order to interface in a common way to the Kernel. Shared 
25 data assures that all applications use the same Machine 
class state information. 

Since the Machine class uses object-oriented design, 
it contains objects that define specific devices with 
possible functions for each device. For example, some 
30 possible functions of the spindle object may be run 
clamp, and stop. The object's data describe the speed 
range and current speed. An operator program may not 
necessarily use all of a Machine class object's functions, 
but the functions are available and supported by the 

35 Kernel. .... - ~ " " ... 

Typically, a copy of the Machine class will be 
attached to each operator application being used in order 
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to provide a common interface to the Kernel. In addition, 
a customer may extend the functionality of the Machine 
class being used, as long as the same Machine class is 
being used by all operator programs. One embodiment of 
5 the Machine class contains the following objects: Push- 
button Console, Jog Pendant, Axis, Axis Group, Spindle, 
Tool Changer, Coolant and Lube. 

The Kernel provides mechanisms for coordinating 
multiple, servoed axes and to provide discrete I/O 

10 control. The CNC applications communicate with the Kernel 
components, the Logic Controller and the Motion 
Controller, through the Machine class. These Kernel 
components decide how to implement the operator programs ' 
commands for the hardware provided. 

15 The Motion Controller provides multi-axis 

coordination as in most commercial CNCs. In its basic 
form, it controls five coordinated axes plus one spindle 
and two auxiliary axes. In addition it supports several 
types of interpolation algorithms including linear, 

20 circular, elliptical, helical, and polynomial. 

Applications communicate with the Motion Controller 
through the Machine class message interface. 

The Logic Controller (LC) contains two programs: 
programmable ladder logic and the LC engine. The LC uses a 

25 window-based programming environment either off-line or at 
the Operator level to simplify production of a logic 
program to run on the LC. The LC also has software tools 
to change, debug, and monitor the operation of the ladder 
logic. 

30 The Platform Services class of the present invention 

provides the structure that allows operator programs and 
third-party software to connect to the system and 
communicate with other software applications. There are 
four services that control system connection and 

35 communication: 
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initialization Sequence - a file, similar to a PC's _ 
autoexec.bat file, listing all operator programs in 
the order that they will start during start up; 
Directory Services - a registry of all active 
programs ; 

Machine Configuration Library - a shared memory area 
to store default machine parameters for application 
configuration. This is similar to the win.ini file in 
the Microsoft Windows system; and 

Exception Reporter - collects, organizes, stores and 
distributes all errors of interest to the active 
applications 

Directory Services contains a 'phone book- that lists 
all running applications. Applications register with 
Directory Services and receive addresses of the other 
applications with which they need to communicate. 
Directory Services does not assume any specific 
communications connections. This means that the system is 
dynamically configurable to allow addition of other 
applications that use the interfaces of an embodiment of 
the present invention. Applications store the addresses 
they receive from Directory Services in their own 
directories. Applications, such as the Kernel, .that need 
machine configuration parameters can retrieve those 
parameters from the . shared memory where the Machine 
Configuration Library stores the information. 

An operating system usable in connection with the 
present invention complies with . IEEE-1003 . 1 POSIX (a 
standard for application programming interface for UNIX) 
and the IEEE-1003. 4 POSIX standard that defines, real-time 
extensions. This embodiment uses the Lynx operating system 
(LynxOS), a real-time, UNIX-like, operating system that 
runs on any 386 PC/AT or greater compatible computer. , 
LynxOS has these characteristics: (1) Compliant with POSIX 
1003.1, POSIX 1003.4 real-time extensions and POSIX . 
1003.4a threads interface; (2) Full UNIX compatibility 
(binary and source with System V, source with BSD 4.3); 
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and (3) Completely deterministic, including Multi-tasking 
with user-defined priority levels, Mult i- threaded support 
for real-time ADA, Offers demand-paged virtual memory, 
Runs off-the-shelf Interactive UNIX System V software 
5 without recompilation, and Networking and communication 
facilities including TCP/IP and NFS. The LynxOS 
development tools including over 170 UNIX-compatible 
utilities and the standard UNIX libraries may also be 
used. The tool set used in one embodiment supports DOS I/O 
10 facilities, Debugger software, Re-entrant device drivers, 
Compilers for C, FORTRAN, Pascal, BASIC, and ADA, GNU 
Package (GCC, Emacs, GDB, C++), X Window System, Motif, 
Network File Sharing (NFS) and Transmission Control 
Protocol/Internet Protocol (TCP/IP) . 
15 The Device Drivers class forms the interface between 

the operating system and the hardware devices such as I/O 
peripherals (e.g., serial communications ports), video 
displays, and mass storage devices. The operating system 
calls these drivers when a device is installed (at boot 
20 time or dynamically) and when application programs need to 
access a device. The device drivers in the embodiment are 
capable of handling multiple devices and respond rapidly 
to high-priority tasks. The present invention contains the 
following types of drivers: PC/AT keyboard and serial 
25 mouse, Analog input/ output card, SCSI device driver, 

Floppy disk device driver, Ethernet interfaces, Internet 
message and transmission control protocol, Internet 
protocol and protocol family, Internet user datagram 
protocol, Pseudo terminal driver, Hard copy and video 
30 terminal interface, NFS client I/O and server drivers, 
CANbus, and MATRIX4 
Detailed Description 

Overview - Hardware 

Fig. 1 is a schematic diagram of a typical CNC 
35 machine on which the control system of the present 

invention may operate. A standard PC-compatible ISA bus 
10 is connected' to CPU processing unit" 11 and its 
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associated Motherboard, preferably an Intel 80486 class _ 
I «o rocessor. The bus may also access RAH memory 
wnich may alternatively be connected 
m otherboard. ISA bus 10 may optionally provide an 
5 interface to network 13. Mass storage device 14 which 
Ly include both hard and floppy disk drives is also 
Zn cted to ISA bus 10, as are standard "ic-ions 
ports 20, motion control board 18 (preferably a DSPCG, 
ports 2U, Matrix 4 / Vector 4 combination 

Inc. (Minneapolis, MN) Matrix * / 
10 mounted on a VHE bus) , and video interface 15 

in one embodiment, the CNC machine specific hardware 
of the system are interconnected via a CANbus "us system, 
tccordingly, CANbus interface card 16 is also positioned 
in ISA bus 10. CANbus cable 17 connects other CNC machine 
1S hardware components and provides 3 og pendant 

therebetween, CNC machine ^ - ° * ^ ^ 
21, and servo motors 25, 26. In general, m 
board 18, or CANbus interface 16 and CANbus cable 17, 
provide means for transmitting command signals to a 
20 movable tool, such as servo motors 22-26 ^'"J**'™ 
or tool fixtures connected thereto. Servo motors 22 24 
control movable tools for shaping a worKpiece. such as X, 
V and Z axes of the machine tool, respectively, whlle^ 
servo motor 25 may control the spindle which 
25 cutting tool. Servo motor 26 may control an tool changer 
which hold, a plurality of worKpiece shaping tools, such 
as milling bits or may control a rotary, table. _ 

The system uses industry standard cards including the 
new CANbus distributed I/O card. This bus allows a user to 
30 XcTnodes to the system rather than insert cards into 
the cabinet. The high availability of the cards Keep 
Prices low and reliability high. Standard board sizes and 
counting holes Keep the system open to changes and 
unorades. Keyboards, trackballs, and 3 og pendants are 
35 connected as CANbus nodes to the system. The Keyboard may 
" Te located away from, the main platform without 

the guality.of the signal, .However „ to. comply, with safety 
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standards, the emergency stop button and the power on/off 
switch are wired directly. 

The control system of the present invention System 
offers two back plane buses: ISA and VME. Both meet LynxOS 
5 and POSIX standards and communicate with the control 

system software. Using CANbus and MATRIX4 with either bus 
permits real-time path correction based on auxiliary 
sensors such as vision, secondary axis, and temperature 
sensors. 

10 The system's I/O backbone is the CANbus, a multi- 

master serial bus. CANbus can be structured to form many 
different architectures because it has different types of 
PC configurations and the CANcore module to standardize 
the interface to I/O peripherals. CANcore acts as a CANbus 

15 node allowing the customer to connect peripheral I/O 
through the industry standard SPI (Serial Peripheral 
Interface) Bus. 

The system uses the MATRIX4 to decrease system 
integration costs, increase motor control system 

20 performance, and create component sourcing options for the 
customer. This controller is a fully digital, 4-axis 
position controller available on both the ISA and VME host 
platforms. The flexibility of the controller design 
allows a user to adapt the controller to any motor design 

25 on the market. The controller is capable of interfacing to 
DC brush, DC brushless, and AC induction motors and allows 
most parameters to be programmed dynamically. This allows 
immediate updates when there are changes in the . 
environment or operating conditions. 

30 Overview - Object Oriented Systems 

An overview of the broad categories of the software 
components of the' CNC machine control system of the 
invention is shown in Fig. 2. In the Operator class are 
software programs generally classified as the Part Program 

35 Interpreter (PPI) or user interface. This type of 

software is generally well-known in the art, and except 
for the way" it communicates the information it obtains to : 
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the remaining software components, does form a part of the 
invention per se. The PPI may either interrogate the 
operator to input steps to machine a workpiece, or may 
prompt the user to specify a data file having a digitally 
5 stored part manufacturing description. Regardless, once 
information about the part is obtained, the PPI 
dynamically creates appropriate objects in the Process 
class as further described below. 

The control system of the present invention uses 
10 object-oriented design and programming object-oriented 
design means that software components are created from 
data and functions and are organized into objects. 
Software components communicate through messages sent 
between objects. Objects have. two parts: data and 
15 methods. Objects are abstract representations of the 
basic things a system handles (e.g. , a spindle, tool 
changer, or type of motion). An object's attributes 
describe the object, but not how it works. The object's 
methods, are instructions, programs , procedures , or 
20 actions that describe what the object will. do when 

something happens. So a spindle object's methods may be 
initialize, run, orient, speed override, and stop. The 
object's data describe the speed range and current speed. 
Using object-oriented programming, objects can be 
25 guickly created using a class, the blueprint for the 

objects/The class establishes the basic variables that 
are common to all of its^ objects,, and the new objects 
inherit these common characteristics from the parent 
class. This feature allows the software engineer to build 
30 on existing design and code by creating more specific 

objects from the easily reused code in the general class. 
For example, a software engineer can use a general class 
of characteristics for a 'device' to create a, model of a 
more specific device such as a spindle. : 

A method belongs to an object^ and indicates how to. , 
perform an action or how to react when an action; is 
performed on the object. The ; system : .may only ..access : data 
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through the methods, if at all. Methods, therefore, hide 
an object's data and send messages to perform operations. 
This isolates dependency on a particular data structure 
thus permitting new features to be added without changing 
5 the arrangement of the original objects. This structure 
protects the data from the damage that commonly occurs 
during changes in monolithic, proprietary systems. 

As with data characteristics, methods can also be 
inherited from the parent class when a new class or object 
10 is created. Of course, the new class or object may use the 
method or create a different version of it. Different 
objects can use identical methods. Therefore, a software 
engineer writes the code for the method only once and then 
reuses it after that. The reusability of existing object- 
15 oriented code makes development and modification faster 
because there is less to write and maintain. 
An additional benefit of using object-oriented methods is 
the localization of change. Data hiding isolates code from 
other code and reusing methods removes the need for switch 
20 statements and other references throughout the code to the 
system's condition or processing state. This limits the 
ripple effect of changes and makes it easier to maintain 
large, complex programs. 

The control system of the present invention software 
25 contains class libraries, of machining software . These 

libraries contain machining procedures and functions that 
can be called with ah expected result. These libraries are 
grouped into object-oriented classes that may be used as 
is and/or extended. The core libraries contain the most 
30 basic characteristics needed for primitive operations. 

The software employs a bi-directional messaging 
interface to facilitate communication between components. 
Messages are passed between the CNC applications (PPI and 
Process Class) and Kernel. Communication from the 
35 applications to the Kernel differs from communication 

between the applications in that Kernel communication is 
more precisely defined for the Kernel; -Each' component 
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communicates through messages. These messages may have 
different requirements. Messages are managed for efficient 
communication. Unordered, independent messages are 
executed immediately. Ordered, dependent messages are 
5 queued. A queue message is not executed until the previous 
message is complete, and each component maintains a 
separate message queue. 

A key feature of the CNC control system of the 
present invention is the ease with which existing systems 

10 can be brought onto the new platform. The obvious 

advantage of this feature is that it preserves features of 
existing systems while providing a migration path to 
future technologies.. There are two ways a user may take 
to move existing software to the control system of the 

15 present invention: (1) porting «C. systems for immediate 
use, or (2) conversion of procedural code to C or C++. 
Machine Class 

The Machine Class is an object-oriented interface to 
the Kernel and Process Class. This class contains the 
20 machine's device-specific application procedures to hide 
the complexity of the Kernel and the message interface 
from the CNC applications. This is accomplished through 
the interface between the Machine Class- and the CNC 
applications (Process Class/PPI) . Applications call 

25 standard functions to the Machine Class objects which 

sends a message to the Kernel. The Machine Class objects 
handle all communication between the Process Class objects 
and the Kernel including the .creation of the - 
communications port, use of appropriate communication 

30 functions, and passing messages back to the CNC 
applications. The specific Machine Class 
responsibilities are allocation of resources and 
connection to the Kernel, message handling ; between the: 
Kernel and the CNC applications, and device state 

35 monitoring and management. . - . 

When the system starts up, the Machine Class 
allocates; the resources that the application .needs and - •■ 
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creates a port to the Kernel from each CNC application. 
After the port is created, the Machine Class logs in to 
the port creating a two-way connection between the Kernel 
and each running application. This allows messages to be 
5 sent back and forth from the applications to the Kernel, 
Multiple copies of the Machine Class may be used in the 
system. In fact, it is customary to attach a copy of the 
Machine Class to each CNC application being used. 
Kernel 

10 The Kernel Class is the mechanism through which CNC 

applications control machinery. The Kernel provides 
mechanisms for controlling discrete I/O and coordinating 
motion axes. This general controller can be used in a 
variety of machining applications. The Kernel contains two 

15 components: Logic Controller and Motion Controller. The 
Motion Controller performs multi-axis coordination. In its 
basic form, it controls five coordinated axes plus one 
spindle and two auxiliary axes. In addition it supports 
several types of interpolation algorithms including 1 

20 linear, circular, elliptical, helical, and polynomial. 
Applications communicate with the Motion Controller 
through a message interface. 

The Logic Controller (LC) engine executes ladder 
logic/GRAFCET programs to control the machine at the 

25 lowest level. There are two programs the LC engine 

executes: the user program and the system program. The LC 
also has tools to change , debug , and monitor the operation 
of the ladder logic. 
Operating System 

30 The real-time, UNIX, execution environment provides 

all of the standard advantages of a real-time environment 
with its diagnostics and response capabilities. In 
addition, X Window is a standard, graphical, user 
interface. X Window permits a variety of input devices 

35 (e.g., mice, keyboards, graphic displays) to be 
simultaneously' shared by several programs . This 
flexibility allows 'developers to leverage their areas of 
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expertise without being concerned about the basic system _ 
graphics. This window-display interface also allows the 
user to run one machine and display its output on another, 
an definite advantage for a CNC application. Motif 
5 manages the windows created by X Window. This manager 
allows the user to control the size, location of windows 
on the screen, and identification of the active window. 
This software also provides a library of X Window items to 
use in system development. TCP/IP is a network protocol 
10 that runs on Ethernet. It allows X Window to perform 

network transparent activities such as remote procedure 
calls. Its file sharing capabilities means that 
programmers do not need to download files. 
Platform services 
15 " The Platform Services Class provides these functions: 
Initialization Sequence - a file listing all 
applications in the order that they will start during 
power up; 

Directory Services - a registry of all active 

20 applications 

Machine Configuration Library - a shared memory area 

holding default machine parameters; 

Exception Reporter - collects, organizes, stores and 
distributes all errors of interest to the active 

25 applications 

Applications register with Directory Services and 
receive addresses of the other applications with which, 
they need 'to communicate. Applications store the 
addresses they receive from Directory Services in their 

30 own directories. Applications, .such as the Kernel, that 
need machine configuration parameters can retrieve those 
parameters from the shared memory where the .Machine 
Configuration Library stores the information. 

Messages between the applications use POSIX message 

35 queues. These queues, are created at run time and have 
unique names. Each application receives^ messages through 
one instrument, but as.when using telephones, . each. 
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application can communicate with many different 
applications. 

The Initialization Sequence is the init script file 
listing all applications in the order that they will start 
5 during power up. It is executed after the operating system 
boots. The Initialization Sequence's primary 
responsibilities are to: 

Load various CNC system drivers (CANbus, MATRIX4, and 
the serial port driver) 
10 Start Directory Services, the Exception Reporter, the 

Kernel, and the user display 

Create the Machine Configuration Library 
Start listed applications 
A user may create and change this script. It should begin 
15 with the device drivers, Platform Services, and the X 

Window System. Other applications in the script may be the 
CNC applications and the motion subsystem and Logic 
Controller within the Kernel. To create or change the 
script, the customer may use an editor (Vi) or the 
20 interactive setup program. The script can also be created 
automatically with the software installation program. The 
following is a representative initialization sequence 
script. 



30 # System Services 
# 

/bin/DirectoryServices 
sleep 5 

/bin/ Except ionReporter 



# 

25 # Dynamically installed device drivers 



# 

dynaminst \ /Devices/MATRIX4 . insttab 
dynaminst \ /Devices /CANbus . insttab 
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# Kernel 
/bin/Kernel & 



# User Applications 
/Apps/bin/Manual & 



Platform fiArviceP Messages _ 

Messages have a standard grammar using command verbs 
with possible qualifiers. There are three types of 
qualifiers: 

Structure - defines a type of variables. 
Enumeration - a list of integer values allowing 
association of constant values with qualifier names. 
Union - a variable that may hold (at different times) 
objects of different types and sizes. It is used to 
manipulate different kinds of data in a single storage 
area without embedding any machine-dependent information 

20 in the program. 

Required qualifiers begin with a capital letter, and 
optional qualifiers use no capitals. 

Message Structure 

Messages used by the Platform Services have this 

25 basic structure: 
Verb Qualifiers 

A verb describes the message request. The verbs used by 

the Platform Services' components are 

Ad d - establishes a phone book listing for an 

30 application 

Get - finds the address of an application or the 

configuration information in shared memory 

Update - supplies new information for an application 
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Ping - checks on the status of an application (active 
or shutdown) 

Request - asks to be informed when a condition has changed 
The qualifiers are data structure names followed by the 
5 data structure elements. These qualifiers can be composed 
of other qualifiers (i.e., dynamic data structures). Verbs 
act on the qualifiers. 
Platform Services Schema 

The schema defines the data structure qualifiers for 
10 all messages and global data used by Platform Services. 
Platform Services' messages use the following qualifiers: 

• String • PhoneListing 

• Description • Value 
FieldPtr . FieldCount 

15 • DataType . ErrorCode 

The following qualifier descriptions contain definitions 
in the form of text and in »C code and the definitions of 
the »c» code data names. 



20 



String 

String is a structure describing a collection of ASCII 
characters. The 'C» data structure follows: 
typedef struct 
{ 

int length; 
25 char characters [ ]; 

} String; 

length = number of characters in the string 
characters = an array of letters, numbers, and/ or 
symbols 

30 Description 

Description is a string explaining a variable concept 
(e.g., an error condition) in a message. The 'C data 
structure follows: 

typedef String Description; . : v 
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neidPtr is an index in to the Machine Configuration 
database. The -C data structure follows: 
typedef int FieldPtr; 
5 FieldCount 

If the field is an array the FieldCount indicates the 

of events in the array. The -C data structure 

follows: 

typedef int FieldCount; 

10 PhoneListing aridress 
PhoneListing is a data structure representing the address 
of an application in a directory list.no. The >C data 
structure follows: 
typedef struct 

15 { 

string processName; 
portName Name ; 
int processID; 
} PhoneListing; 

20 processNa-e - na»e identifying the application^ 
^ortNa„e = n« .f the connection port for the 
application identified 

prLssID - integer code identifying the appHcatxon 
DataType 

25 DataType is an enumeration of data representations. The 
'C 9 data structure follows: 
typedef enum 
{ 

undefined; 

30 integer; 

floatingpoint 
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} DataType; 

Undefined = data type not specified 
Integer = data consisting of whole numbers 
Floatingpoint = floating point data 
5 String = data expressed with characters 

Value 

Value is a union representing a variable data type. 
DataType defines the data's size and type. The •C data 
structure follows: 
10 typedef union 

{ 

int integer; 

double floatingpoint; • 
String string; 
15 } Value 

integer = data consisting of whole numbers 
floatingpoint = floating point data 

string = data expressed with characters 

ErrorCode 

20 ErrorCode is an enumeration of exceptions. The "C data 
structure follows: 
typedef enum 
{ 

NoSeverity; 
25 Information; 
Warning; 
Fatal; 
} ErrorCode; 

NoSeverity = error of uncategorized severity 
30 Information = error message providing information only 
(no action required) 

Warning = error indicating application is having 
difficulty completing the task " 
Fatal = error indicating application is .not able to 
35 complete current task 
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Directory Services 

Directory Services functions as a registrar for the system 
applications. The responsibilities of Directory Services 
are to - 

5 Maintain a list of applications in the system 

Periodically check (ping) applications to see if they 

are still running 

Provide queue addresses of registered applications 
Applications register in the Directory Services' 
10 phone book by listing their unique ASCII names. Then 
before an application can communicate with another 
application, it requests the POSIX message queue address 
from Directory Services' phone. book. Each application has 
its own phone book. It lists only the addresses of other 
15 applications with which it needs to communicate. 

Application Shutdown 

Directory Services periodically pings all registered 
applications to be certain that they are still running. If 
an application has shut down, Directory Services removes 

20 the shut-down application from the list of registered 

applications, destroys its copy of that application's port 
connection, and informs all remaining, registered 
applications that the application has shut down. At that 
point, the applications decide if they need to disconnect 

25 from the shut-down application. Applications clean up 
after disconnecting by removing the reference for the 
shut-down application from their own directories. 

Messages to Directory Services 

Applications send messages to Directory Services to 
30 register in the phone book and to retrieve phone. book 
entries of other applications. These messages use the 
standard message structure described previously. 
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Add 

An application may send an Add message to Directory 
Services to establish a phone book listing for the 
application. The Add verb uses the PhoneListing qualifier 
5 with the required elements Name, PortName and ProcessID. 
The message structure is - 

Add PhoneListing <Name> <PortName> <ProcessID> 
Elements 

The elements for the Add verb can use a string of ASCII 
characters . 

<Name> ASCII character string 

<PortName> ASCII character string 
<ProcessID> number representing the process ID 
Sample Message: 

Add PhoneListing LC LCportll94 151 
Expected Responses 

When Directory Services adds the new entry to its phone 
book, an •Added 1 response is sent to indicate that the 
phone listing was successfully updated. A 'NotAdded 1 
20 response is sent if Directory Services was not able to 
update its phone listing. 

Added PhoneListing <Name> <PortName> <ProcessID> 
NotAdded PhoneListing <Name> <PortName> <ProcessID> 
Description <errordescription> 

25 Sample Response: 

Added PhoneListing LC LCportll94 151 

Get 

An application may send a Get message to Directory 
Services to find the address of an application with which 
30 it wishes to communicate. The Get verb uses the 

PhoneListing qualifier. The message structure is - 



10 
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Get PhoneListing <ProcessName> 
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Elements 

The ProcessName qualifier is a string of ASCII characters. 

<ProcessName> ASCII character string 
Sample Message: 

5 Get PhoneListing LC 

Expected Responses 

When Directory Services retrieves an entry from its phone 
book for a requesting application, it sends a 'Got' 
response to indicate that the phone listing was 
10 successfully retrieved. A 'NotGotten- response is sent if 
Directory Services was not able to find the phone listing. 

Got PhoneListing <Name> <PortName> <ProcessID> 
NotGotten PhoneListing <Name> 
Sample Response : • • •■ 

15 Got PhoneListing LCLCportll94 46 
Messages from Directory Services 

Directory Services sends messages to applications under 

two conditions: . 

Checking to see that the application is still active 

20 (Ping) 

informing applications that another application is no 
longer active (Update) 

These messages use the standard message structure 
described previously. 

25 Ping 

The Ping verb uses the ProcessName qualifier. The message 
structure is - . ■ 

■ ... ■ • • :: .. ic: 

Ping <ProcessName> 
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Elements 

<ProcessName> ASCII character string 
Sample Message: 

Ping LC 
5 Update 

Directory Services sends the application an Update message 
to inform an application of a change in another 
application's status. The Update verb uses the 
PhoneListing qualifier and has this structure - 

10 Update PhoneListing <Status> <description> 
Elements 

<Status> enumeration of status conditions 

<description> ASCII string of characters describing 
the status condition 
15 Sample Message: 

Update LC shutdown 

Machine Configuration Library 

The Machine Configuration Library provides default 
parameters for applications in a shared memory area. This 
service's responsibilities are to 

Load 1 and distribute initialization parameters from 
the file system 

Distribute parameters to applications 
Some common parameters may be maximum acceleration, 
maximum RPM for the spindle, and travel limits and feed 
forward gains for each axis. Applications access these 
parameters under three circumstances: 

During application start-up for initialization 
parameters 
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During run time when operational parameters are 
needed 

When tuning or another operation makes it necessary 
for an application to refer to its configuration 
parameters 

This parameter library uses a C++ object, System 
Variables, to read and write data in the globally 
accessible shared memory area. The library also contains 
utilities to create, load the configuration, print, list, 
save, restore, and remove the information in the System 
Variables memory region. 

g yg-hP.m Vari ^^l^s Object 

The System Variables object supports seven. data types: 

Bytes 
15 Strings 
Doubles 

...Integers. ^. :?r '"' "' /. 

Short Integers 

Long Integers ' - '• ~ 

This object also includes methods for saving and reading 
the parameter information to and. from disk., , The System ,. 
Variables methods are listed below: 



20 
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BasePtr,- returns, the base, pointer to the , shared memory 
Close - "closes a connection, to , the shared area. 
Field . calls the SVField. object- (described in ,the 
following section) to find a field specified by the field 



FieldCount - . gets the number of elements for the field 
and returns the parameter count. 

FieldSize.-; gets the, size of the field. and, returns the 

parameter size. " ' ' 

FieldType - : .get S the data type and returns,^ for 
byte. •!• for integer, -D- for double, -s- for string. ?H 
for short integer, or a' for long integer. 
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FileName - returns the configuration file name used to 
define the shared data area. 

Some additional System Variable methods are listed below: 



10 Name - returns the shared area name specified in the 
configuration file. 

NumberOf Fields - returns the number of fields defined 
for the System. Variables. 

PostSemaphore - . : releases the semaphore used to 
15 synchronize access to the shared area . 

Remove - deletes the shared area completely from the 
system. 

Restore ; — places a saved binary copy of the configuration - 
parameters into the shared- area. 1 - — * :v V- 

20 Save - makes a binary copy of the configuration 
parameters and places it on the disk; • [ J 

Size - returns the total size in bytes of the shared " 
area (not the amount of shared area being used) 7 : ■ - ^ 
WaitSemaphore r-) - gets' the, semaphore : used to : synchronize 

25 access to the shared: area. - " ■ ■ "'-"'"'^'^ rw-- s 
The PostSemaphore and WaitSemaphore methods allow a u 
program to access the shared area' 1 and'- send several : ; J ' :v 
messages without the overhead of getting and releasing the 
semaphore for each Get and" Update 'message. This approach ' 

30 saves time. 

SVfield Object 

The System Variables object uses "the System Variables- 
Field (SVfield) object to describe each field. Using this 
object improves efficiency of the field access function by 



Get 



finds configuration information in shared 



memory. 

Update - places new configuration parameters in shared 
memory for an application. 

GetField - traverses the list of fields in the shared 



area. 
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providing detailed field information and eliminating the _ 
search for individual fields. 

This object contains the following methods: 

Name - supplies the name of the field (up to 31 
characters including a null terminator) . 
Type - supplies the field data type ('B- for byte, I 
for integer, 'd. for double, ... for string, for short 

integer, or "L" for long integer). 

Count - supplies the number of elements that may be 
stored under the field name. Elements are numbered 
beginning with zero. 

Size -" supplies the size of each field element. In 
386/486 systems, integers and doubles are stored in four 
bytes while strings are variable length. 

15 Utilities 

There are several utilities -available to create and manage 
the Machine configuration shared data and the memory area: 

SVcreate - builds a configuration file. ■. : a 
svsize - checks the configuration file's, size and , 
20 recommends a minimum size. ,:. r - . - - • ■■■■'■■>'-" ~ - 

SVprint r, displays the, field name, data type (B, I, H, L. 
D, S), the count (number of elements), and the size of " 

each field... ;c:^:i « :ork: - - - - !V ' " ' _ 

SVloadConfig - , ,, places, the default, values xnto the , , 

25 shared memory, area. 

SVlistData - creates a file showing all of the data 
values currently stored in the shared memory area. 
SVsave - makes a copy of the shared memory area under the 
file name specified in the configuration file. 
SVrestore.- dumps the shared area in hex bytes to be 
used for detailed debugging tasks. 



30 
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SVremove - deletes the shared area from the system. 
The configuration file and any binary 'save 1 files are 
left intact. 

SVshmdump - displays the shared area in hex bytes. This 
5 can be used for low-level debugging. 

Messages to Machine Configuration Library 

Applications send messages to the Machine Configuration 
Library. 

Get 

10 An application may send a Get message to the Machine 

Configuration Library to access information. It uses this 
format: 

Get Qualifier 

Get FieldPtr * v 

15 This message requests the <fieldPtr> or the Field 

Description. If the <f ieldPtr> is zero/ 'then this message 
requests the pointer to the description <name>. If the 
Description is empty, then this message requests the 
description of the field pointed to by <fieldPtr>. It is 

20 an error if the <f ieldPtr> is" zero ; and the Description to 
be empty. — 

Get FieldPtr : <fieldPtr> Description <name> ^ 

Elements " 

The elements for the Get verb are - 

25 <fieldPtr> Pointer to a field in the 

Configuration Library 
<Name> Name of the Field 

Sample Message: 

Get FieldPtr 0 String "MaxTravelX" 
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Expected Responses 

configuration Library returns the following: 
Got FieldPtr <fieldPtr> Description <naiae> 
NotGotten FieldPtr <fieldPtr> Description <name> 
5 Description <errorDescription> 
Sample Response: 

Got FieldPtr 253 String "MaxTravelX" 
Get Description 

This message is used to request information about the 
10 Fields in the Machine Configuration Library. The Fields 
can be described either by using the name or a field 

^Description <name> Qualifier FieldPtr <fieldPtr> 
Get Description <name> Qualifier Description <fieldName> 

15 Elements 

The elements for the Get verb are - 



20 



25 



<name> 



30 



name of the information requested from 

. a field: -. 

Field Count • M" 
.... , Field Size.; r - - 
. Field Type -.-v..-: 

Field value 

Qualifier TheQualif ier is a place holder for 

the results of the Get. It also 
specifies the data format (int, float, 
string) of the desired result. 

<FieldName> Name of the field 

<FieldPtr> Pointer to the field 

Sample Message: 

Get Description "Field Count" int <count> FieldPtr 23 
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Get Description "Field value" Floatingpoint <value> 
Description "MaxTravelX" 

Expected Responses 

Configuration Library returns the following: 
5 Got Description <name> Qualifier FieldPtr <fieldPtr> 

Got Description <name> Qualifier Description <fieldName> 
Sample Response: 

Get Description "Field Count" int 10 FieldPtr 23 
Get Description "Field value" Floatingpoint 23.5 
10 Description "MaxTravelX" 

Update 

Update Description 

This message is used to change information about the 
Fields in the Machine Configuration Library. The Fields 
15 can be described either by using the name or a field 
pointer. 

Update Description <name> Qualifier FieldPtr <fi'eldPtr> 
Update Description <name> Qualifier Description 
<fieldName> • '•• ' ^ - > 

20 Elements ? 

The elements for the Get verb are : "i\' v r 

<name> name of the information requested from 

a field: " — ' Vi ' i; ■ " ^ - 

Field value 

25 Qualifier The Qualifier is new value for the 

field 

<FieldName> Name of the field 

<FieldPtr> Pointer to the field 
Sample Message: 
30 Update Description "Field value" int 10 FieldPtr 23 
Update Description "Field value" Floatingpoint 23.6 
Description "MaxTravelX" r lv 
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Expected Responses 

Th e configuration Library returns the following: 
Updated Description <na m e> Qualifier Field 

Ptr <fieldPtr> . 
5 updated Description <na»e> Qualifier Description 

<f ieldName> 

Sample Responses: ' _ 

... nt.^iH value" int 10 FieldPtr 23 
Updated Description "Field value ixrc 

"pHeld value" Floatingpoint 23.6 
Updated Description "Fieia vaiue 

10 Description "MaxTravelX" 

Exception Reporter 

The Exception Reporter receives all -^^^ 
messages (e.g., servo faults) sent by the Kernel. 
Exception Reporter responsibilities are to - 
15 . Receive error reports for applications and Kernel 
Distribute error reports to applications 
^is maKes error handling unifor. . across ^^TZ* 
ZZZZZ ^ ^cepr^eUrto receive 
20 particular types of messages. Xn addition the Exception 
Lporter Keeps a list of ail current pending error 
ne ssages. When an application, starts up and checks in, 
can receive all messages of interest to it. 

Applications specify the severity, and/or, category of 
25 errors they -ant to receive. So an application may^t.1 
the Exception Reporter to notify it when any I/O 
ere grated, another application .ay want to be informed 
only of the fatal errors that shut, down the machine. 

Error Messages and severities 

that the applications only receive xn 
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There are two basic types of messages in the Exception 
Reporter queue: 

One-shot messages 

Latched messages 
When a one-shot message arrives, the Exception Reporter 
determines which applications need to receive the message, 
sends copies of the message to those applications, and 
then removes the message from its queue. When a latched 
message arrives, the Exception Reporter determines which 
applications need to receive the message and sends copies 
of the message to those applications. However, latched 
messages are not removed from the queue until another 
message arrives instructing the Reporter to remove the 
stored message. The latched messages that have not been 
cleared form the group of current pending messages that a 
newly started application may need to receive. 



The messages may have three severities: 
Information - describes a condition that may be of 
general interest to other applications. 

20 Warning - indicates that operation of the machine has 

halted though the power is still on. The operator may need 
to take some action to continue operations. 
Fatal - tells the system applications that the servo amp 
has been shut down and the power has been taken away from 

25 the machine control hardware. The operator must take some 
action to resume operations. 

There are also categories of errors that may be of 
interest to applications: 

Motion 
30 Logic Control 

Device Layer 

Directory Service 
Of course, the customer may also define additional error 
categories. Then when a message arrives, the Reporter 
35 matches its severity and category with the types of 

messages each application indicated it wanted to receive. 
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motion control messages, and another m y 



control errors. 



fntered in this manner, the one- 
^Z^rZ^Z ail interested applications 

^removed from the gueue. A ll ~ queue 

broadcast to interested applications and kept 
until specifically removed by another message. 



15 



m ° S ZZ7:* ~nt « t h e Exception aeporter eitner report 
an error or revest error insertion. There are two 
used in the Exception Reporter messages: Update 
Request . 

UPdat6 To inform an application of an error condition, the 
ExC eption Reporter sends the has 
message. The Update verb uses the Error gua 
this structure - 

Update Error <ErrorCode> <description> 

20 Elements . , „ e 

<£rrorcode> enumeration o£ exceptions 
<aesoription> ASCII strin, of. characters descrrbrn, 
the error 

Sample Messages: 
25 Update Error Fatal loss of encoder; X axis 
Expected Responses 

Z Exception Reporter sends the error message to an 

, L If the error message was successfully sent, 
application. If the error * mess age was 

,* returns an 'Updated' message. If the error m 
it returns an p ret urns a 'NotUpdated' message. 

30 not sent successfully, it returns 
The responses use these formats: 

Updated Error <ErrorType> 
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NotUpdated Error <ErrorType> <ErrorValue> Desc 

<errordescription> 

Request 

An application may send a Request message to Exception 
5 Reporter to ask that it be informed of specified error 
conditions. 

Request ErrorCode <Code> 
Elements 



10 Sample Message: 

Request ErrorCode Fatal 
Expected Responses 

There are two expected response verbs: Requested and 
NotRequested. Both verbs use the ErrorCode qualifier. 
15 Requested ErrorCode <Code> 

NotRequested ErrorCode <Code> 
Operator Class 

Operator Class applications include part programming 
software. The conversational language used in a fully- 

20 featured package has a question/ answer format using 

multiple choice and f ill-in-the-blank questions/ as well 
as clearly worded operator prompts. To further simplify 
part programming, the system displays graphic 
illustrations of plan view, side views, and/or an 

25 isometric view with dimensional scaling in the X, Y, and 
axes • 

The conversational part programming package features the 
following: 

• Packaged Cycles 

30 ♦ Part and Toolpath Graphics Verification for 
Conversational and NC programs 

• Programmable Safety Areas 

• 'No-Calc'- Programming 



<Code> 



enumeration of exceptions 
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Estimated Run Time 
99 Tool References 

Automatic Speed and Feed Calculation 
Inch/Metric Programming 
Modal Parameter Blocks 
Automatic Rough/ Finish Pass 
Data Block Search 
After the operator completes a part program, there are 
several additional features of the software that can be 
10 used to improve efficiency and accuracy: 
Error Checking 
Test Run Function 
Program Review 
Program Text Printout 
Graphics Printout 
Upload/Download Utility 

The automatic calculation feature allows the system 
• to calculate certain unknown dimensions after sufficient 
information has been entered. This feature computes and 

20 displays Cartesian and polar data for a programmed move. 
For example, if the 'X- and -Y- end coordinates are 
entered, the system automatically calculates the XV length 
and the XY angle parameters. The XY angle is the angle of 
the line segment (from start point to end point) measured 

25 counterclockwise from the 3 o'clock position. If the XY 

length and the XY angle are entered, the system calculates 
the • X ' and • Y 1 end coordinates . 

Cutter Compensation 

When beginning the part program, the operator 

30 describes all of the tools that will be used. Then the 
program can automatically allow for the diameter of the 
tool when determining the toolpath for an inward spiral or 
when connecting milling segments. With cutter compensation 
in use, the tool is offset from the print line a distance 

35 equal to the radius of the tool. The operator: may also 
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indicate whether to compensate on the right as in 
conventional milling or the left for climb milling. If the 
cutter compensation feature is not needed, the operator 
does not select it as an active option when programming a 
5 block. 



Packaged Cycles 

Packaged cycles are pre-programmed, common machining 
operations such as drilling, tapping, pecking, and boring 
and reaming. Since the system contains packaged cycles, 

10 the operator can specify a type of operation and define 
only the necessary variable information. Then the system 
makes additional calculations to define the operation 
fully. For example, when the operator is programming a 
drilling operation with pecking, the operator simply 

15 specifies the peck type and depth and the system uses a 

canned cycle to determine the exact movements of the drill 
- during the pecking process. 

RS-274-D Package 

A RS-274-D package provides conventional NC (G-code) 

20 programming capabilities. This package allows the operator 
to save and load part programs to and from remote 
computers running CAD/ CAM applications or other peripheral 
devices (e.g., paper tape readers) . Communication between 
these devices is handled over RS-232-C serial ports. 

25 The NC editor in this package has the following features: 

• Character insert or overwrite modes 

• Optional sequence numbers 

• Automatic sequence numbering by a programmable 
increment 

30 • Block-to-block cursor moves (forward and backward) 

• Character-to-character and word-to-word cursor moves 
(forward and backward) 

• Jump to program beginning or end or scroll up and 
down on one page 

35 • Jump to block or sequence number 
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jump to or replace a matching NC word 
Automatic syntax checking of NC data blocks 
10 -element tag queue for • bookmarking ■ the program 
Jump to one of the tags 
NC block insert and delete 
Copy, move/or delete a range of NC blocks 
interaction with the graphical system for program 

TcTrlrlrcan be loaded into oonversational PPXs through 
10 this interpreter. 

PPI Messages 

The Part Program Interpreter messages have the 
standard grammar using command verbs with possible 
qualifiers. There are three types of qualifiers: 

15 Structure - defines a type of variables. 

Enumeration - a list of integer values allowing 
association of constant values with qualifier names. 
Union - a variable that may hold (at different times) 
objects of different types and sizes. It is used to 

20 manipulate different kinds of data in a single storage 
area without embedding any machine-dependent xnformatxon 

in the program. 
Required qualifiers begin with a capital letter, and 

optional qualifiers use no capitals. 

25 Message Structure 

Any of the Part Program Interpreters used m the 
system have the same basic message structure: 
Verb Qualifiers 

A verb describes the message request. The verbs used by 

30 ^nterlret" " finds information about the axis positions 

Update^ supplies new information about the axis position 
and speed 
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The qualifiers are data structure names followed by the 
data structure elements. These qualifiers can be composed 
of other qualifiers (i.e., dynamic data structures). Verbs 
act on the qualifiers. 

5 PPI Schema 

The schema defines the data structure qualifiers for 
all messages and global data used by any Part Program 
Interpreter (PPI). The messages use the following 
qualifiers: 
10 • String 

• Description 

The following descriptions of these qualifiers contain 
definitions of the qualifiers in the form of text and in 
f C f code and the definitions of the 'C f code data names. 

15 String 

String is a structure describing a collection of 
ASCII characters. The data structure follows: 

typedef struct 
{ 

20 int length; 

char characters [ ] ; 
} String; 

length = number of characters in the string 
characters = an array of letters, numbers, and/ or 
25 symbols 

Description 

Description is a string explaining a variable concept 
(e.g., an error condition) in a message. The 'C 1 data 
structure follows: 
3 0 typedef String Description; 
Interpreter Messages ■ 

Any Part Program Interpreter working in the system 
must use two standard messages: Interpret /and Update. ' 
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""^Interpret messages sena pieces of an 
program to the Interpreter, 
interpret Description <programBlock> 

,. rorts the ppi to begin execution 
The Interpret message directs the m 

of the Part Program. 

<programBlock> RS-274 program block 

™ e r:zz7z able to «. ^» « 

responds with an fnterpreted message. « the PP! » not 
able to interpret the message, it responds with a 
Hotmterpreting message. The expected responses for any 
the Interpret commands are 

interpreted <Qualifier> <er rordescription> 
reinterpreting <Qualifier> Description <errorde 

UPdat L RS-274 program is made up of many models. The 
init ial values of Lse models can be set using the Update 

message. , . _ . ,. 

Update Description <modalName> Qualifier 

< ro odal N ame> Name of the Modal to be modified 

Qualifier contains data type and a value 

for the modal. 

. "fTe^nd. with an Updated message to indicate^ 

' that the mode! has heen set. If the modal is undefmed, an 
NotOpdating error message is returned. 

updated <««" fi ^ r> Desoription <err0 rdescri P tion> 
Notupdating <Qualifier> Descnp<-i 



30 
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machines. OEMs can modify the parameters for the 
following: 

• Kinematics 

• Servo Tuning 

5 • Safety Regions 

• Maximum Feeds and Speeds 

• Lead Screw Mapping 

• Remote Communications 

• Language 

10 Version control of configuration files permits the 

integrator to extend previous versions of parameters and 
record the changes for backtracking purposes. 
Machine Class 

The Machine Class of . the control system of the 

15 present invention forms a device-oriented interface 

between the Kernel and the CNC applications. The Machine 
Class establishes and monitors the CNC applications 1 
connections to the Kernel and handles messages between the 
applications and Kernel. Each application includes a copy 

20 of the Machine Class to facilitate a common interface to 
the Kernel. Also, shared data assures that all 
applications use the same Machine Class state information. 

Since the Machine Class uses object-oriented 
design, it contains objects that define specific devices 

25 with all of the possible functions for each device. For 
example, a spindle object may have the possible functions 
of run, clamp, and stop. The object's data describes the 
speed range and current speed of the spindle. A CNC 
application may not necessarily use all of a Machine Class 

30 object's functions, but the functions are available and 
supported by the Kernel. 

A CNC application may also hook into packaged 
cycles from the Application Tool Kit. These cycles define 
common machining operations such as drill, bore, J and tap 

35 and operate at a higher level in the control system than 
the Machine Class. By using these same Machine Class 
object methods, a customer may 'customize and expand the 
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10 



15 



pa c* a ged cycles to meet specieli-d ^ " 

L the details of Machine class „ e used 

Multiple copies of the Machine class may 

in the control system. It is recommended that a copy of 
m the centre y appUcetxon 
the Machine Class be attaoneo c int „ tao e to the 

Wing used in order to provide a common interface 
Kernel. In addition, a customer may extend the 
"net onality of the Machine Class being used as 1 n, 
copies of the same Machine Class are being used by 
applications-^ ^ ^ ^ 

claS ses according to the present invention: (1, Mr 1 mg 

Tes^st in gaining an gain understanding of the message 
interfece. The Milling Machine Cless is one that mey be 
implemented for e besic milling machine. 

Hilling Marine Class custome rs with 

The Milling Maichine Ci a ss allows cu 

filing machines to become Mediately T ° 
use this Machine Class, customers simply link to the 
use tni* pmc application and gam 

Machine Class library with their CNC appn 

access to the following objects: 
o Flow Control 

Push-button Console 
o Jog Pendant 
o Axis 

Axis Group 
o Spindle 
j o Tool Changer 

o coolant 

o Lube . 
All of these objects eilow e CNC epplicatron to 
grab ownership of. the device, initialize the device ^ 

4. ef a f 0 and release ownership. When an 
_ „„r,;+-o-r its current state, ana tei caac 

5 monitor its cuii. device, it then has 

application has grabbed ownership of a device, 
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the authority to issue action requests to that device 
using the methods provided. The Milling Machine Class can 
also be used in combination with the packaged cycles in 
the Application Tool Kit to customize the operation of a 
milling machine. 



Sample. Generic Machine Class 

A sample Machine Class may be used as a pattern 
to develop new Machine Classes. It contains the minimum 
object-oriented devices with their methods that are needed 
10 to operate a typical machine tool: 

Flow Control - controls the communication 

from the CNC application to 
.the Kernel f s synchronous 
queue . 

15 Push-button Console - reserves all necessary 

buttons and lights on 
the console for an 
application. 
Axis - allows an application 

20 to control an 

individual axis or 
joint. 

Axis Group - user-defined groups of 

coordinated axis moves 
25 (e.g., X, Y, Z, A, and 

B). 



Spindle - 
Tool Changer - 



30 



basic functions of a machine 

tool spindle. 

basic functions of a tool 

changer. 



35 



Shared Memory 

In an alternate embodiment of the invention, an 
area of the computer's memory is reserved for the Machine 
Class information. The shared memory contains ownership 
and state information for each device. : Each copy of the 
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Machine Class looKs at this region to a== s in formation _ 
about the devices. However, acoess to this area is 
controlled so that appXications can only view and change 
device information through the Machine Class. 

5 RlO£3 St C""°rshin „„.„,. tD 

Since multiple applications may attempt to 
access the same device, the concept of device ownership is 
access cne u.chine Class. Ownership 

central to the operation of the Machine cias 
of a device means that an application has reserved that 

L0 device though the application may not he using device 

the moment. , ^,,n 

The application that • owns ■ a device has full 

access to it while other applications have read-only 
access. Applications are permitted to send messages to 

15 devices only if they have ownership of those devices 

This rninirni.es the inter-component logic reguired for any 
application often used to determine permission conditions 
for e command. However, some decision logic is still 
needed within each application. 

systems with only a single application may be 

" structured to never grab ownership of a device. In this 
situation, there would be a single owner of all devices. 

nnmmun i c a t ions , 

Messages to the Machine Class devices can 

25 originate from several sources: 

Part Program Interpreter 

o User Interface 

Push Buttons on the Console or Jog 

Pendant 

Sensor Interface 
To simplify system operations and programming, 
the control system has a specific division 
between its components. For .example, the Machine Class 
Toes not worry . about the Kernel • s responsibilities^ 
3S travel limits and servo errors.. Conversely, .the Kernel 



WO 95/07504 ^■VUS94/10029 



59 

is not concerned about ownership or devices because the 
Machine Class handles that exclusively. 

This system structure also simplifies system 
communications and complies with the open systems concept. 
5 CNC applications may communicate with the Kernel through 
any or all of the system layers. For specific functions, 
the customer's software engineer may bypass a layer and 
connect an application directly to the next layer or 
another layer down. This, of course, is accomplished 
10 through the standard message formats supplied for each 
control system component. 

Communication Connections 

An application may communicate to the system 
components in two ways: (1) Through the system layers; or 
15 (2) Directly to the components. When an application uses 
the Machine Class layer, three advantages result: 

1. Automatic message sequencing to the 
Kernel components (Logic and Motion 
Controllers) 

20 2. Ownership handling for multiple 

processes 

3. Simplified communication to devices 
The control system permits communication through 
the Machine Class layer to the Kernel components. To 

25 operate efficiently, a CNC application's part program 
interpreter and its user interface (also called a man- 
machine interf ace-MMI) need the operational simplification 
provided by the packaged cycles from the Application Tool 
Kit and the features of the Machine Class. 

30 However, some programs do not need the features 

of these middle layers. For example, the diagnostic and 
tuning programs within a CNC application are not concerned 
with the system's devices or ownership rules. These 
specialized programs can communicate efficiently by 

35 connecting directly to the Kernel functions. Another 

program that bypasses the middle layers is the Exception 
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Tt is not interested in the machine devices or 
rtl'K^r^tions an, can connect directly t. «- 

B essa,in, ^— Ber u using only one CNC vacation 
s to control the entire system that application must manage 
device access between different parts of the program. 

HMM3 ^1 h f Machine Class messages use the qualifiers, 
Xisted in the schema below, to define the messages. 
L0 Qualifiers are data structure names followed by the data 
structure elements. These qualifiers can be 
other qualifiers (i.e., dynamic data structures). The 
„essa,e verbs, described in the following section, act 
these qualifiers. 

15 string , . 

String is a structure describing a 

collection of ASCII characters. The -C data 
structure follows: 

typedef struct 

20 { 

int length; 
char characters! ]; 
} string; 

length - number of characters in the 

25 Strin9 characters- an array of letters, numbers, 

and/ or symbols 

DataTvpe . 
DataType is an enumeration of data 
30 representations. The data structure follows: 

typedef enum 
{ 

Undefined; 
Integer; 

FloatingPoin^- 
JO 
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String; 
} DataType ; 

Undefined - data type not specified 

Integer - data consisting of whole numbers 

5 Floatingpoint - double precision floating 

point number 

String - data expressed with characters 

Value 

Value is a union representing a variable data 
10 type. DataType defines the data's size and type. 

The 'C 1 data structure follows: 
typedef union 
{ 

int integer ; 
15 double floatingpoint; 

String string; 
} Value 

integer - data consisting of whole numbers 

floatingpoint - floating point data 
20 string - data expressed with characters 

AxisID 

AxisID is an enumeration describing an 
individual axis. The •C data structure follows: 
typedef enum 
25 { 

Xaxis; 
Yaxis; 
Zaxis; 
} AxisID 

30 Group 

Group is a structure describing a group of axes. 
The 'C 1 data structure follows: 
typedef struct 
{ 

35 int id; 

int number Axes ; 



eft 
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AxisID axes[] ; 
} Group 

id _ Axes group id 

number Axes - number of axes in group. 
Range 1 - NumberAxis^ 
5 axes - array of AxisID' s 

State 

State is an enumeration of the current 

* ThP 1 C data structure 

conditions of a device. The <- 

10 follows: 

typedef enum 

{ 

Uninitialized; 
Calibrated; 
15 Stopped; 

at orientPosition; 

y State 

Uninitialized - object has not been 

initialized. ...„. eH 
20 calibrated - object has been calibrated. 

Stopped - object is not moving 

OrientPosition - object has arrived at the 

orient position 

para^Pterlnfo 

„ Parameterlnfo is a structure describing 

information specific to a device. An example of a 
>C data structure for a tool changer follows: 
typedef struct 
{ 

30 int toolID; 

int CarouselPosition; 

} parameterlnfo 

toolID - integer representing the tool 

identification number. 

Range: 1 - Number-Tools^, 

35 

voioffitvTVPe 
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VelocityType is an enumeration of velocity 
representations. The 1 C 1 data structure follows: 
typedef enum 
{ 

5 Undefined; 

XYZ; 
XYZAB; 
Spindle; 
} VelocityType 

10 XYZ - velocity for 3 axis machine 

XYZAB - velocity for 5 axis machine 
Spindle - velocity of the spindle 
Velocity 

Velocity is a structure describing speed and 
15 direction. The , C I data structure follows: 

typedef struct 
{ 

VelocityType type; 
Value data; 
20 } Velocity 

type 
the structure 
data 

25 

Override 

Override represents a speed multiplier. The ' C f 
data structure follows: 

typedef double Override; 
30 Override - representation of speed 

multiplier. Value of one (1) 
indicates 100%. 
Range: 0.1-2.0. 

Increment • 

35 Increment represents a delta position. The 'C 1 

data structure follows: 

typedef double Increment; 



indicates the type of velocity data in 

velocity data; Units of (m/sec) for 
linear axis and (radian/sec) for 
rotary axis. 
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15 



merest- representation of a delta move^ _ 
Units for increments are meters. 

Offset is a structure describin, Delta position. 
5 The 'C data structure follows: 

typedef struct 
{ 

int count; 
double delta [] ; 

in } Offset . 

1 coun t - number of axes deltas described in 

structure, 
(range 0 -maxAxes) 
delta- array, of axis deltas. Meters are 

used for linear axis, and radian 
is used for rotary axis. 

Feedrate , n * 

Feedrate represents coordinated linear speed of 

the Cartesian axes. Feedrate uses units of 

~ The 'C data structure follows: 
(meters/second) . Tne <- uai,a 

typedef double Feedrate; 

linear is a Qualifier used with "Move., verb to 
describe a linear move. The 'C data structure 

25 follows: 

typedef struct 

{ 

position endPosition; 
Attributes attributes [ ] ; 

in } Linear 

endPosition - represents the linear position at 

the end of the move . 

attributes - attributes describe condition 
that affect the move. 'Until 
Limit Switch' is an example of an 
attribute. 



20 
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Tool is a Qualifier used to describe a tool. 
The 'C data structure follows: 
typedef struct 
{ 

5 int toolID; 

} Tool 

toolID - Integer representing the tool 
identification number. 

Range: 1 - NumberTools^ 

max 

10 Gear 

Gear is a Qualifier used to describe gear ratio. 
The , C data structure follows: 
typedef struct 
{ 

15 int gearlD; 

double gearRatio 
} Gear 

gearlD - integer representing the gear 
identification number 
20 gearRatio - floating point number 

representing the gear ratio 



Machine C lass Message Formats 

The Machine Class messages begin with verbs to 
describe the message requests. These verbs reflect the 

25 actions of the methods listed for the device objects 

described in the next section. In the list below, each 
verb is defined and possible message formats are shown 
after the definitions. Many Machine Class verbs stand 
alone to direct the actions of objects. For those verbs, 

30 no message formats are not listed. 
Grab 

Requests ownership of a specific device. 
UnGrab 

Releases ownership of a specific device. 
35 Initialize 
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Establishes default parameters necessary to 
operate a device. 

° nIni : o rces\ re-initialise of a specific 
device (must initialise after this vert » 
used) • 

Retrieves the current information from a 
specific device. ^ Descrlption <name > Qualifier 

Get <ParameterInfo> 

"^Establishes a specific operational 
parameter for a device.^ ^ ^ <name> Qualifier 

Update <Override> 

Update <Gear> 

Update <Feedrate> <value> 

Mamies, special operation of a specific 



device. 



Enable <Power> 
DlS Tisables special operation of a specific 



25 device. 



30 



35 



Disable <Power> 
"^Engages the clamp on an axis or spindle. 

"""'^engages the clamp on an axis or spindle. 

Calibrate 

Establishes a reference point for a 

specific device. 

Begins continuous operation of a specific 

device. 

Cycle 
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Marks the starting position of a sequential 
operation of a specific device. 
Cycle Description <cycleID> 

Move 

5 Engages coordinated operation of a specific 

device 

Move Linear 
Move Velocity 
Move <Increment> 

10 Dwell 

Begins null operation of a specific device 
for a specified time. 

Dwell Floatingpoint <time> 

Stop 

15 Ceases operation of a specific device in a 

manner that makes recovery possible. 
Cancel 

Ceases operation of a specific device 
immediately (recovery will not be 
20 possible) . 

Step 

Engages the predefined operation of a 
specific device in a forward direction. 
UnStep 

25 Engages the predefined operation of a 

specific device in a reverse direction. 

Machine Class Objects 

The Machine Class's objects are representations 
within the system of the devices on a machine and the 
functions necessary to manage those devices (e.g., flow 
control, tool changer, axis, and spindle). All Machine 
Class objects have two parts: data and methods. 

The object's methods, are instructions, 
functions, procedures, or actions that describe what the 
object does in response to an event. A method belongs to 
an object and'indicates how 7 to perform an action or how to 
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react to an external event. An application may only _ 

...» obiecfs data through its methods, if at all. 
access an o£>:jeci: s uai - . . „ c The Machine 

Hethods send messages to perform operates. The M 
Class objects with their methods are described in the 
following sections . 

embodiment of the invention, the 
control systems Milling Machine Class's Flow Control 
object controls the communication between a CNC 

* .ho Kernel's synchronous queue. This 
application and the Kernel s sy commU nications 
object allows a CNC application to set up 
port to the Kernel and monitor the current state of the 
Kernel for the application. An application must get 

\ nf the Flow Control object to gain control of 
ownership of the Flow conrr j folloW ing methods are 
the Kernel's synchronous queue. The following 

included in this object: 



20 



25 



Grab - 
UnGrab - 
Initialize - 



30 



Get <State> - 
Enable <Power> - 

Disable <Power> - 

Run - 

Stop - 



35 



requests ownership of the 
Kernel's synchronous queue, 
releases ownership of the 
Kernel's synchronous queue, 
establishes default 
parameters necessary to 
operate the Kernel's 
synchronous queue . 
gets the current active state of 
the Kernel's synchronous queue, 
enables power for the 
Kernel's synchronous queue, 
disables power for the 
Kernel's synchronous queue, 
directs the Kernel to 
process synchronous requests 
continuously... 
directs the Kernel to stop 
processing requests from the 
synchronous queue. 
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Cancel - directs the Kernel to stop all 

activity immediately and flush 
the queue. 

ste P - directs the Kernel to 

process a single request in 
the synchronous queue. 

Push-butto n Console Object 

The Milling Machine Class's Push-button Console 

object allows an application to initialize and reserve all 
10 necessary buttons and lights on the console. In this way, 

the operator can press buttons to control power, start a 

cycle, hold the motion of the machine, and interrupt an 

operation while an application monitors these actions. 

When an operator presses a button, a message is sent to 
15 the application controlling that button. If the buttons 

are not enabled by an application, they are ignored by the 

Logic Controller. 

The following methods are included in this 

object: 

20 Initialize - establishes default parameters 

necessary to operate the push- 
button" console. 
Grab " requests ownership of the push- 

button console. 

25 UnGrab - releases ownership of the push-button 

console. 

Get " requests specified information 

from system components. 
Enable - enables remote operation on the push- 
30 button console. 

Disable - disables remote operation of the push- 
button console. 

Update - establishes a specific operational 

parameter for the push-button console. 

35 Jog Pendant Object 

The Milling Machine Class's Jog ^Pendant object 
allows an application to initialize and reserve all 



WO 95/07504 



CTAJS94/10029 



Bes sage ^ately ^ not enabled by ,„ 

r P r::r- l. nr rr = in this 

The following methods are mum 



object: 



10 



15 - 



initialize - 



Grab ~ 

UnGrab - 
Get - 

Enable - 



establishes default parameters 
necessary to operate the jog 
pendant . 

requests ownership of the jog 
pendant . 

releases ownership of the jog pendant. 

requests specified information 

from system components, 
enables remote operation on the jog 



pendant . 



20 



Disable - disables remote operation of the jog 
pendant . 

^^e Milling Machine Class's A xis object allows 
an application to control an individual ~ is 

• M , hnds are included in this ob]ect. 
The following methods are establishes def 



25 



an axis. 



Initialize - 



Grab - 
UnGrab - 



30 axis. 



Get <State> - 

state of an axis. 

Get <ParameterInfo> - 

parameters 



establishes default 
parameters necessary to 
operate an axis, 
requests ownership of 

releases ownership of an 
gets the current active 



returns current 



35 



Clamp - 



engages the clamp on an 



axis. 
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15 



20 



25 



30 



35 



UnClamp - 

axis. 

Calibrate - 
point for an axis. 

Move <Velocity> - 
specified velocity. 

Move <Increment> - 

distance. 

Stop - 
Axis Group Object 

The Machine Class's Axis Group object describes 
a user-defined group of axes. The axis group handles 
multiple axis motion for coordinated moves such as linear 
and circular and time-coordinated joint moves (point-to- 
point) . The object defines the axes' kinematics, handles 
ownership, and includes these methods: 



releases the clamp on an 

establishes a reference 
moves the axis at a 
moves the axis a specified 
halts axis motion. 



Initialize - 



Grab - 



UnGrab - 
axis group. 

Get <State> - 
state of the axis group. 

Get <ParameterInfo> - 
parameters . 

Move <Linear> - 



establishes default 
parameters necessary to 
operate the axis group, 
requests ownership of 
the axis group, 
releases ownership of the 



gets the current active 



returns current 



Move <Joint> - 



engages coordinated 
operation of the axis 
group as defined by the 
point vector, feedrate, 
attribute, and 
termination type, 
engages coordinated 
operation of the axis group 
using point-to-point time 
coordination. 
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Update <Group> - 
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pauses in motion defined by ^ 
time in tenths of seconds. 

(axes) identifies which 
axes belong to this 
group . 

Update <Override> - indicates the feedrate 

override factor. ,• testes the speed 

Update <Feedrate> - (value) indicates tne P 

applied to a given Axis 

Group. 

indicates the offset 

used for Part Zero and 

other general offsets. 

Th e Axis Group object has these additional 

Enable<Power> - enables power to the axis 



20 



25 



Update <Offsets> - 



group 
group . 



Disable <Power> - disables power to the axis 
stops the specified axes. 



Stop - 

spindie object describes all possible 
functions of a machine tool spindle. Tbis object grabs 
ownership of the spindle axis and sends 
Logic controller to initialize, enable, and handle the 
spindle's orientation angle, the maximum RPMs, and all 
otner necessary operations. This Machine Class object 
contains the following methods- 



30 



35 



Initialize - 



Unlnitialize - 



Grab - 



UnGrab -. 



establishes default 
parameters necessary to 
operate the spindle, 
forces a re- 
initialization of the 

spindle . 

requests ownership of 

the spindle, 
releases ownership of the 
spindle. 
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Get <State> - gets the current active 

state of the spindle. 
Get <ParameterInfo> - gets current 

information parameters 
5 for the spindle. 

Run - begins continuous 

operation of the 
spindle in the 
specified direction and 
10 at the RPM of the move. 

Update <Override> - overrides the speed by a 

specified factor. 
Update <Gear> - initiates a remote 

change of the spindle's 
15 gear speeds. 

Clamp - holds the tool in the 

spindle. 

Unclamp - releases a tool from the 

spindle. 

20 The Spindle object has these additional methods: 

Enable - enables remote operation of the 

spindle's manual push-button. 
Disable - disables remote operation of the 

spindle's manual push-button. 
25 Stop - stops motion of the spindle. 

Tool Changer Object 

The highly detailed Tool Changer object 
describes all possible functions of a tool changer. This 
object has access to the data indicating the number of 
30 tools in the changer, the current tool in the spindle, and 
the carousel position. The tool changer grabs ownership 
of the required resources such as the spindle and axes. 
The tool changer uses the storage slot number rather than 
the tool number for positioning. The tool number and 
35 related data are included in the Tool database. This 
object contains the following methods: 
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Initialize - 



Unlnitialize - 



Grab - 



UnGrab - 

Get < State > - 



15 



20 



25 



30 



35 
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establishes default 
parameters necessary to* 
operate the tool 
changer . 
forces a re- 
initialization of the 

tool changer, 
requests ownership of 
the tool changer, 
releases ownership of the 
tool changer, 
gets the current active 
state of the tool changer.. 

Get <ParameterInf o> . - gets current 

information parameters 

for the tool changer, 
sets the storage slot number 
for a tool in the spindle, 
enables remote operation on 
the tool changer, 
disables remote operation of 
the tool changer. 

sets the indexer 
position. 

Tni s tool changer object also contains these methods: 
cycle - marks the starting position, of a 
sequential operation of the tool 

changer. . : 

halts tool changer motion, 
moves the tool changer one 
logical step at a time. 

£2SlaBtJ ^co 01 a„ t aescri.es aU ^ • < 

fun ctions o £ the cedent wechanis*. Tnis coolant oo,ect 
conteins the foliowino o>mership of the 

Grab - 14 / . 

coolant device. 



Update <Tool>- 
Enable - 
Disable - 
Calibrate - 



Stop - 
Step " 
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UnGrab - 

Get <State> 
the coolant device. 

Stop - 



releases ownership of the coolant 
device, 

gets the current active state of 



10 



15 



20 



25 



30 



35 



Run - 



Enable - 



Disable - 



indicates when to stop the 
coolant. 

begins continuous 
application of coolant and 
identify the type of coolant 
(mist, flood, or both) . 
enables automatic clearance plane 
detection and automatic shut- 
off. 

disables automatic clearance 
plane detection and automatic 
shut-off. 

Lube Object 

The Lube object describes all possible functions 
of the lubrication mechanism. This lube object contains 
the following methods: 

requests ownership of the 
lubrication device, 
releases ownership of the 
lubrication device. 
- gets the current active state of 



Grab - 



UnGrab - 



Get <State> 
lubrication device. 

Stop - 



indicates when to stop the 
lubrication. 
Ru n - begins continuous 

application of lubrication. 
Kernel-Machine Class Communication Example 

The following communication example demonstrates 
data moving through the Machine Class to the Kernel 
components. In this example, the CNC application is 
operating a spindle using the following steps: 

1 . Application grabs ownership of the Spindle . It 
receives an »0K' or a 'Reserved 1 response. 
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2. 
3. 



10 



4. 

15 



^plication requests SpindleBun 
Machine class sends these requests to 

controller: ^ ^ ^ contro iier to 

voltaqe to the spindle axis) 

„ update <Flag> SpindleAtSpeed (drrects 

to report when up to speed) 

. wait until LCfla, (directs MC to wart for 
LC flag before continuing) lrmfltet 

4 . T he Motion controller returns 'OK or •ConfUct 

"^T^'The Motion controller sends a Spindleoear 
re ,uest to Logic controller and warts for 

""xLte. spindle enahle and gear change 

o spindleOrient = Off 
o spindleEnable = On 
o spindleOn = On 
. select gear speed based on RPM 
, LC sends request to MC to creep spxndle axxs. 
8 MC sends -atCreep- message to LC. 

rf an error occurs an error 
ft r selects gear. If an erro1 , 
" Message is sent to the Exception reporter and 
the Machine Class flushes the queue 
LC sets LCflag to satisfy first MC Waxt 
(indicates that it is OK to start axxs). 
M begins spinning the SpxndXe axis 
MoV e parameters. If an error occurs, send an 
error message to Exception Reporter, and the 
Machine. Class flushes queue. 
MC gives SpindleAtSpeed request to.LC. 



6 

20 logic: 



25 7 



10. 

11. 
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13. LC waits for SpindleAtSpeed input or time-out. 
If an error occurs, send error message to 
Exception Reporter, and the Machine Class 
flushes queue. 
5 14. LC sets LCflag to satisfy second MC Wait 

(indicates sequence is complete) . 

15. LC sends Completion response to Application (if 
requested by Application) . 

16. Machine Class sets DalState = SpindleRunning (if 
10 requested by Application) . 

Customizing a Machine Class 

The open systems design of the control system of 
the present invention permits modification of the Machine 
Class to handle machines that have not been used by the 

15 control manufacturer. This is possible because the 

devices are independently defined from the relationships 
between the devices. The Kernel's Logic Controller and 
the applications handle the actual device 
interdependencies during operation. 

20 a system user may add features to a device 

definition and/or modify the characteristics of the device 
without being forced to change other devices. This allows 
the customer to develop an implementation of the system 
customized for a specific machine. 

25 The Machine Class's object-oriented design 

allows software engineers customizing the Machine Class to 
quickly create new Machinie Class objects by inheriting 
from existing Machine Class objects and then modifying 
them. Because of the advanced programming features of 

30 C++, a software engineer need not alter the source code of 
the control system for the objects in order to modify 
them. The new objects then inherit the common data 
characteristics from the parent objects. This feature 
allows software engineers to build on existing design and 

35 code by creating more specif ic objects from the easily 
reused code in the existing Machine Class objects. 



WO 95/07504 



■CT/US94/10029 



78 



10 



15 



20 



- rr:: r r r;: s~ « - «- — - 

created. Of cours , Meth ods send messages 

a different version of it. « eui 
create a differen isolat es dependency on a 

to perform operations. This isoi featU res to 

particular data structure thus P-~«» ^ 
be added without changing the arrangement of 

objects. 

221221 The Kerne! of the control system provides 
mechanisms for coordinating motion "^^^ can 
input/output (I/O) control. This general contr 

^ Z * variety of machining applications. The cnc 
be used in a variety oi _ conp0 nents, the 

applications communicate with, the Kernel P 
LO gic controller (LC) and the Motion Controller («C) , - 
^ugh ^Machine class^ ^ ^ 

components communicate "^Y^ects caUed Usages . 
applications through special objects =^ 

use a common message structure, ana 
These messages use co coin ponent has an 

Spending on the retirements of the 

s^chronous ^esseges are order^and, theref «. _ P ^ 
' ^rrsstrare independent of previous messages 
so that they can be executed immediately. 

SSEM ^1 n f system messages provide two-way : • 
, communication between the applications and the Kernel -.■ 
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components. These messages have the following 
capabilities: 

Single commands 

Initialization parameters and configuration sent 
5 through the messages 

Synchronous messages are queued 
Asynchronous messages are executed immediately 
There are different categories of messages: 
Flow control 
10 Parameters 
Diagnostics 
Requests 
Data 
Error 

15 Message Structure 

The messages of the control system of the 
present invention have a standard grammar using command 
verbs with possible qualifiers and variable attributes. 
There are three types of qualifiers: 
20 Structure - defines a type of variables. 

Enumeration - a list of integer values allowing 
association of constant values 
with qualifier names. 
Union - a variable that may hold (at 

25 different times) objects of 

different types and sizes. It is 
used to manipulate different 
kinds of data in a single storage 
area without embedding any 
30 machine-dependent information in 

the program. 
In the list of messages presented below, 
required data elements begin with a capital letter, and 
optional elements use no capitals. Messages used by the 
35 Kernel have this basic structure: 

Verb Qualifiers 
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A verb describes the message request. , 
„ *. structure names followed by the data 
Qualifiers are data can be coinpoS ed of 

structure element • Thes^ structures) . Verbs 

other qualifiers (i.e., ayuau 

5 ■* °" the T retI" S " S e a W th. Kerne! components are - 

_ is used to control the 

execution of the synchronous 
buffer (MC and LC) . 
StopRun - is used to control the execution 
of the synchronous buffer (MC and 

LC) . 

directs the Motion Controller to 
move. along a linear path or move 
at fixed velocity. 

tells the MC or the LC to 



10 



Move - 



15 



Wait - 



20 



25 



30 



StopWait - 



Get - 



Update - 



Flush - 



not execute any messages 
after the Wait message until 
a stopWaiting message is 
sent. 

tells the MC or the LC to 
begin executing messages 
again. 

tells the MC or LC to send 

information to an 

application, 
tells the MC or LC that an 
application wants to. change the 
value of a parameter, 
tells the Motion Controller to 
delete all of the messages in its 
synchronous queue. 



35 



vot-t^i Qualifiers m .. saae 
The Kernel's schema describing the message 
qualifiers is shown on this and following pages. The 



WO 95/07504 ^ ^T/US94/ 1 0029 



81 

qualifiers define the data structures for all messages and 
global data used by Kernel. 
String 

String is a structure describing a collection of 
5 ASCII characters. The 'C 1 data structure follows: 

typedef struct 

{ 

int length; 
char characters [ ] ; 
10 } String; 

length - is the number of characters in 

the string, 
characters - is an array of letters, 
numbers, and/or symbols. 
15 Name 

Name is a structure that identifies the subject 
of the message with a descriptive term. The 'C 1 data 
structure follows: 

typedef String Name 
20 Description 

Description is a structure used to define the 
basic characteristics of the subject of the message. 
The 'C data structure follows: 

typedef String Description 

25 Value 

Value is a union representing a variable data 
type. DataType defines the data's size and type. 
The 'C data structure follows: 
typedef union 
30 { 

int integer; 
double floatingpoint ; 
String string; 
} Value 

35 integer - is the data consisting of whole 

numbers. 

floatingpoint - floating point data. 
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10 



string- is the data expressed with 

characters . 

Posi£ionTMBg . - position 

representations. The c 
typedef enum 

{ 

Undefined; 

XYZ; 
XYZAB; 
ZS; 
Spindle; 

} posit ionType „ a „hi n e 
X YZ - position for 3 axis machine. 

XYZAB - Position for 5 axis machine. 
15 zs _ position of the Z axis and 

spindle - position of the spindle. 

m . ascribing a position for the 

™ is a S - UCt 7J:^; b a :: g str P uc ture follows, 
X and Y and Z axes. The c 
typedef struct 

{ 

double x; 
double y; 
double; z ; . 
> xyz; ... 

x - position for the X axis. 



20 



25 



35 



v - X (units: meters) 
Range: X min * 

position for the ' 
Range: Y min - Y^ 
position for the 

Range: . Z^,, - Zmax 

^XYZAB is a structure describing a position for 

XYZAB is Linear position 

the X and Y and Z and A and B axes. 



v - position for the Y axis. 

30 3 v - Y (units: meters) 

Range: Y nin - 

z - position for the Z axis. 

7 (units: meters) 
Panae: Z„ ; „ - Z„ x (uniw» 
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10 



is expressed in meters. Rotary position is expressed 
in radians. The 'C 1 data structure follows: 

typedef struct 

{ 

double x 
double y 
double z 
double a 
double b 
} XYZAB; 



15 



x - 



y - 



z - 



a - 



b - 



position for the X axis. 
Range: X min - X max (units: meters) 
position for the Y axis. 
Range: Y min . - Y^ (units: meters) 
position for the Z axis. 
Range: Z min ~ Z^ (units: meters) 
position for the A axis. 
Range: A min - A^ (units: 
position for the B axis. 



20 



Range : B, 



- B, 



max 



(units: 



radians) 
radians) 



ZS 



25 



30 



35 



ZS is a structure describing a position for the 
Z axis and the Spindle. Linear position is expressed 
in meters. Rotary position is expressed in radians. 
The "C data structure follows: 
typedef struct 
{ 

double 2; 
double spindle; 

} ZS; 

z - position for the Z axis. 

Range: Z min - Z^ (units: meters) 
spindle - position for the spindle, 
(units: radians) 
Position 

Position is a structure describing a position. 
The 'C 1 data structure follows: 
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15 



20 



25 



30 



35 



typedef struct 
{ 

PositionType type; 
Value data; 
} Position 

typ e - indicates the type of position 
d ata in the structure. ^ ^ _ ^ 

for a linear axis and for a 
rotary axis. 

eSD ^ntact is an enumeration types of physical 
oontact for attributes. For example, a probe 
attribute is a move until a probe makes contact or 
break contact. The data structure follows: 

typedef enum 

{ 

Undefined; 
Make; 
Break; 
} Contact 

Make - .contact is made. 
Break - contact is broken. 

F T^y>ipnisable ' if 

• ^ab^Isable is an enumeration describing if 

attribute is enabled For example, the Feed rate 
override is enabled or disabled. The data 
structure follows: 

typedef enum 

{ 

Undefined; 

Enable; 

Disable; 
} EnableDisable 
Enable - turn on attribute. 
Disable : - : turn off attribute. 
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20 
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TerminationType 

TerminationType is an enumeration describing the 
ending condition of a move. The »C data structure 
follows: 

typedef enum 
{ 

Undefined; 
PrecisionEndPoint ; 
NoDeceleration; 
} DecelerationType 

PrecisionEndpoint - end point of line 

must be reached 
with in in- 
position 
tolerance. 

NoDeceleration - Move is part of 

continuous contour. 
End point is not 
important. 

AttributeType 

AttributeType is an enumeration of attributes. 
The 'C f data structure follows: 
typedef enum 
{ 

undefined 
Limit Switch 
Probe 
Overrides 
MotionHold 
Absolute 
Incremental 
Deceleration 
Concurrent ; 
} AttributeType 

LimitSwitch - indicates that the move is 

terminated on either make or 
break of limit switch. 
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10 



Probe - 

Override - 

MotionHold - 

Absolute _ 

Incremental - 

Deceleration 
Concurrent - 



15 



indicates that the move is 
terminated on either make or 
break of probe, 
enables or disables override 

for move. 

enables or disables override 
for move. 

position is described in 
absolute coordinates, 
position is described in 
incremental coordinates. 
- deceleration attribute, 
this move can be 
concurrently executed with 
another move . 



20 



25 



30 



35 



linear is a ouaiifier used with the Move verh to 
describe a linear move. The >C aata structure 
follows: 

typedef struct 
{ 

Position position; 
Attributes attributes; 

} position t 

indicates the endpoint of 

the linear move, 
attribute modifying the 
motion description. 

V -*^ t ^ is an enumeration o £ velocity 

The 'C data structure follows, 
representations. The <- 

typedef enum 
{ 

Undefined; 
XYZ; . 

,.. XYZAB; : ; . 
Spindle 



position - 



data - 
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} VelocityType 

XYZ - velocity for 3 axis machine. 
XYZAB - velocity for 5 axis machine. 
Spindle - velocity of the spindle. 

5 Velocity 

Velocity is a structure describing a position. 
The , C 1 data structure follows: 
typedef struct 
{ 

10 VelocityType type; 

Value data; 
} Position 

type - indicates the type of velocity 
data in the structure. 
15 dat a " velocity data; Units of (m/sec) 

for linear axis and (radian/sec) 
for rotary axis. 

VelocityMove 

VelocityMove is a qualifier used with the Move 
20 verb to describe a constant velocity move. The 'C 

data structure follows: 
typedef struct 
{ 

Velocity velocity; 
25 Attributes attributes; 

} VelocityMove 

velocity - - indicates the rate and the 

reference frame of the move, 
attributes - attribute modifying the 
30 motion description. 

RunAttribute 

RunAttribute is an enumeration of Run message 
attributes.- The 'C data structure follows: 
typedef enum 
35 { 

Undefined; 
SingleCycle; 
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Immediate; 
; EndOf Cycle; 

MotionHold; 
} RunAttribute 
SingleCycle - 



10 



Immediate - 

EndofCycle - 
MotionHold - 



requests that the motion 
control stop after the end 
of each cycle, 
requests that the motion 
command be executed 
immediately. 

marker for separating moves 
in a cycle. . 
indicates a motion hold 



15 



20 



condition. • 

^^rCode is an elation ot types of error 
codes. The •€• data structure follows: 

typedef enuro ■ 

NoSeyerity; 
Information; . • 
Warning; . :rj - : ? 



25 



Fatal; 
} ErrorCode 
NoSeverity 



30 



35 



error .of ,uncategorized 
severity tK ., 
information. error message providing 
5 - il ; ; information only (no action 

required) ... .. •„. 
Warning - error indicating application 

is having difficulty 
completing the task . 
Fatal - T I error indicating .application 
is not able to complete 
current task. 



WO 95/07504 ^^T/US 94/ 10029 



89 

Motion Controller 

The Kernel's Motion Controller performs multi- 
axis interpolation generating target points for the servo 
hardware. The Motion Controller supports high speed 
5 spindles (up to 60,000 RPM) , rigid tapping, encoder jog, 
and touch probing. An exemplary motion controller has 
these features: 

* Five (5) coordinated axes plus one (1) spindle 

* Programmable interpolation rate - 5 milliseconds 
10 to 20 milliseconds 

* Provides status information for - 

* position (command and actual) 

* velocity 

* following error- 

15 * Leadscrew and backlash compensation using 

linearly interpolated tables 

* Leadscrew compensation corrects for mechanical 
error up to 200 times "per second 

* 5 millisecond block transfer rate resulting in 
20 more detailed information -being processed faster 

* Non-linear control for circle compensation 

* Acceleration control regulates velocity, 
allowing tighter coordination between more than 
one axis while minimizing mechanical wear 1 on : the 

25 • machine } x :r " r " y ^ 

.* Coordinated interpolation with L the 7 spindle 

* - Programmable calibration -and referencing : ' ' 
■ ■• sequence"' " : ' - c " ■ '* - 

* Enhanced Servo Algorithm interfaces with the 
30 motion controller board tomonitor machine 1 

position 10,000 times per second 



35 



Conf iauration Parameters of the Motion Controller 



The Motion Controller configuration parameters 
define the travel limits, PID gain parameters, kinematics, 
and additional miscellaneous parameters. 
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Travel Limits 



^ s parameter establishes the valic i travel 
limits. They can be negative to positive or positive 
to negative along the X, Y, and Z axes. 

5 EJO Cain Par asetegs ed 

The gain parameters are usea 
loop centre! of each axis ,x tc b) . These parameters 

are - 

proportional (P) 
0 integral (I) 

derivative (D) 
integral limit 
velocity feed forward . 

The parameter values are downloaded to the 
appropriate hardware for controlling the axis Then, 
the modified FID algorithm with velocity feedforward 
residing on the. hardware controls ^ 
The Application Tool Kit may be utilized to set 
and adjust the parameters.- 

on Pi^graBBnab lf KiBgga&iSS :: . '""'"V. „ 

D ..The,user may specify ; the, relationships 

between axes to support a variety of axis 
configurations. The forward «" 
position and,the, orientation of the; end-effector 
given the joint angles. . The.. ^^^^ 
determine the joint angle given the positioned 
orientation of : the end-effector. The possible 
kinematics parameters are - 

X position = X 0 J 0 + X,J, + X 2 J 2 + X 3 J 3 V* 
Y position = Y 0 J 0 + * V: + V* + 

30 Z position - Z 0 J 0 +. 8* t. W + Z 3 J 3 + W 

A position = Vo + Vi + A 2 J 2 + ^ + V * 
B position = Vo. + B 1 J 1 ■ + ' B * , i + B 3 J 3 + B ^ 
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Miscellaneous Motion Control Parameters 

Some additional parameters that can be set 
by the Motion Controller are - 

* DAC (digital analog converter) balance 
5 parameter 

* Maximum acceleration 

* Axis sense 

* Axis resolution 

* Maximum rotary RPM 

10 * Limit switch to marker pulse (index 

pulse) 

* Lead screw compensation table 
Motion Controller Messages 

The messages of the ..control system are objects, 
15 such as C++ objects. Each message object is transmitted 
in binary form to the receiving application^ mailbox and 
then rebuilt into an object. This section describes the 
Motion Controller message verbs: r 
Run - Update 

20 Move StopRun - 

Wait Flush : * ' r ' 

Get StopWait ' : ' 

Modals establish a condition that persists until 
another modal changes it: The Motion Controller modals 
25 are : - ' : ' • " 4 ' * * '■ • : - '-^ 

OverrideEnable * 

MotionHoldEnable • : 

IncrementalEnable 

DecelType 

30 These modals can also be used as one-shot modals 

within messages to temporarily set a modal value during 
the execution of the message and restore the mode prior to 
execution. The concurrent modal, used only as a one-shot 
modal, tells the system that a message is"~l inked to the 

35 next message and that both must be executed as one. This 
could span more than one pair of messages. 
Run 
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15 
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The Run messages are used with the StopRun 
aessagt to centre! the execution of the synchronous 
buffer. The Run message asKs the Motion Controller 
to start executing messages from its queue. 
Run <Qualifier> 
Run RunAttribute <attribute> 
The Run RunAttribute directs the Motion 
Controller to begin execution of the messages in the 

synchronous buffer. 

attribute> none 

Singlecycle The Run SingleCycle directs 
the Motion Controller to 
execute messages in the 
synchronous buffer a block 
at a time. Block are 
delimited by 

SingleCycleHeader messages. 

Pv pectec' Ppgponses 

If the Motion Controller is able to begin 
execution of messages from the synchronous 
buffer, it responds with a Running Message If 
the Motion Controller is not able to execute the 
messages from the synchronous buffer, it 
responds.with a NotRunning message. The- 
expected responses for any of the run commands 
are _ Running <Qualifier> 

NotRunning <Qualifier> Description 
<errordescription> 

stopRun . 
_ ^ StopRun message is sent to the Motion 
Controller to halt the execution of the message in 
the synchronous buffer. The motion can halt 
execution of message immediately (with controlled 
deceleration of motion) or at a block boundary. 
Block boundaries are delimited by Cycle Headers. 
StopRun RunAttribute <attribute> 



25 



30 



35 
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This StopRun message asks the Motion Controller to 
stop execution of the synchronous buffer. 
StopRun RunAttribute <attribute> 
attribute> immediate deceleration motion at 

5 the maximum 

acceleration rate. 
SingleCycle - stop execution at the 

first block end 
(singleCycleHeader) 

10 with out exceeding 

maximum acceleration. 

Expected Responses 

When the Motion Controller receives a StopRun 
message, it halts execution of the message in 
15 its synchronous buffer and responds with a 

StoppedRunning message (format below) . 
StoppedRunning <Qualifier> 

Move: 

The Move message in. the Motion Controller has 
20 two qualifiers: Linear and Velocity. The Move 

message uses this basic structure: 
Move <Qualif ier> <attributes> 
Move Linear 

The Move Linear message directs the Motion 
25 Controller to move along a linear path. The path is 

defined by the position specified in the message from 
the end point of the previous move. The message 
structure is - 

Move Linear <Position> <attribute> 
30 Elements 

<Position> XYZ 
"XYZAB 
ZS 
S 

35 <attribute> until switch <breakjmake> 

until probe <breakjmake> 
find index pulse 
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override <enable|disable> 
motion hold <enable!di S able> 
probe <enable',disable> 
<absolute j increraental> 
decel <type> 
concurrent 

Sample Messages: 0 until swi t ch 

Move Linear XYZ iu xx.j- 

brM * „ove Linear XVZA 10.5 20.0 100.1 

f indlndexPulse 

Expected Responses 

NotMoving < Q ualifier> <attributes> 

Descri p t i. <~^^ iBT> <attribu tes> 

Move VelocityMove 

The VelocityMove message asks tne 
Motion controller to move its axes at a 



20 



-specified velocity. 

.Move VelocityMove = <Velocxty> 



<attribute> 



25 



Elements . 

<velocity> XYZ 

, „ .. . . XYZAB ' " ■: 
- • ■ XYZABS aw 

' ;;..r.. . : . < a ttribute>;- , until, switch 2; /; 

<break|make> un til probe <break',make> 

find index pulse 
3° override <enable | disable> 

taction hold <enable!disable> 
probe <enable',disable> 
decel <type> 
concurrent. 



35 



Expected Responses ^^ hute > 
Moving VelocityMove <Velocity> <attrxbute> 
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NotMoving VelocityMove <Velocity> <attribute> 
Description <errordescription> 

Wait 

A Wait message is usually sent to the Motion 
Controller's synchronous queue. The message asks the 
controller to not execute past this message until a 
StopWaiting message is sent. 
Wait Message 

Wait message <id> 
Sample Messages: 

Wait message 1152 
Expected Responses 

Waiting message <id> 
NotWait message. <id> Description 
<errorDescription> 

StopWaiting Message 

The StopWaiting message is sent to the Motion 
Controller to cancel a Wait message. 
StopWaiting message <id> 
Expected Response 

StoppedWaiting message <id> 

Update 

An Update message is sent to the Motion 
Controller when an application wishes to change the 
value of a parameter. 

Update Name <FieldName> DataType <Type> Value 

<Data> 

<Type> Description 
floatingpoint Sets the value of the 
feedrate to be used by 
the following motion 
blocks 

Set the value for the 
feedrate override. 
Enable or disables the 
effect of, the feedrate 
override 



<FieldName> 
Feedrate 



Override 



35 OverrideEnable 



floatingpoint 



EnableDisable 
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MotionHoldEnable EnableDisable 

EnableDisable 

Probe 

5 zeroPosition Position 
Header Header 

10 



15 



20 



25 



30 



35 



Enable or disables the 
effect of MotionHold 
Enable or disables the 
probelnput 

Set the Zero for the 
coordinate system 
The Update Header message 
allow the applications 
sending the messages to 
the Motion Controller to 
embed User Header 
information into the 

Queue . 

Ex pected Hane <FieldHM e> DataType <Type> 

Value <Data> Description <erroru 

^ *o the Motion Controller 

h G et messa 9 e » sent to the^ ^ £roB 

when an application wishes to *=« SS 

the Motion controller. The »essaoe alio ^ 

application. to *™ Zse 
and state variable and BOtron registers 

registers are - 

Current position. 

Index position 
Probe position 
Commanded position 
Velocity 
Following Error 

^ Tt Mame <Pield N ame> Data.ype < T ype> 

<Pield N ame> <Type> 

■» Position, Holds the 
Probe position of the 

Positi ° n axes at the 
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Index 
Position 



Position 



10 



15 



Current 
Position 

Commanded 
Position 



Following 
Error 



Position 



Position 



Position 



last probe 
contact. 
Holds the 
position of the 
axes at the 
last index 
pulse. 

Gets current 
position of the 
axis 

Gets the 
commanded 
position of the 
axis 

Gets the 
following error 
for the axis 



Velocity 



Velocity 



20 



Gets the 
velocity of the 
axis 



<FieldName> <Type> Description 

Override floatingpoint Gets the value for the 

feedrate override. 
OverrideEnable EnableDisable Indicates if Override is 
25 enabled. 

MotionHoldEnable EnableDisable Indicates if MotionHold 

is enabled. 

Probe EnableDisable Indicates if Probe is 

enabled. 

30 Expected Responses > • ' 

Got Name <FieldName> DataType <Type> Value 

<Data> 

NotGotten Name <FieldName> DataType <Type> 
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The Flush message is sent to the Motion Controller 

when a application wants the Motion Controller to 
delete all of the messages fro, its synchronous message 

5 queue . 

Flush <ProcessName> 
Expected Responses 

Flushed 

No tF lushed 

10 MrvMnn Con troller Notes 

The following describes some of the control 
options which may be desired in the Motion Controller 
according to the present invention. 
ralibrat- i^ Sequence 

The Motion Controller contains a programmable 
sequence of primitives which include: 
Move until not limit switch (off) 
Move until index pulse 
Move to index pulse 
20 update position 

Update position offset 
Probing 

The Motion Controller's probing configuration 
includes: 

25 Move to position on probe head 

Move until not probe (off) 

T,naic Co ntroller. 1 y -. .*. 

T^ernel's Logic Controller (LC) is an engine 
that executes logic programs by scanning inputs, executing 
30 programs, and then writing outputs to operate the machine 
tool. The LC has these features: 

Executes ladder logic programs 
Executes GRAFCET programs 

Supports local or bussed I/O including CANbus 

35 and Pamux 

Programmable scan rate down to 20 milliseconds 
and dependent on the size of the program 
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Programmable off-line or on-line 
Program using existing off-the-shelf products 
Supports on-line LC monitoring 
Supports on-line I/O monitoring 
5 On-line debugging 

Simulation 

Communicates through messages 
Supplies a window-based translator to 
convert common, logic control file formats 
10 into the LC file format 

Optional embedded Logic Controller in hardware 
with programmable scans down to 1 millisecond 
Logic Controller Messages 

The messages of the logic control are objects, 
15 such as C++ objects. Each message object is transmitted 
in binary form to the receiving application's mailbox and 
then rebuilt into an object. Three types of message can 
be sent to the Logic Controller: 

Synchronous queue control (Run, Stop) 
20 Send data (Update) 

Access data (Get) 
When the Logic Controller receives user-defined messages, 
it stores them in its data table. Logic must be added to 
the ladder program to evaluate and execute the message. 
25 An example of a user-defined message appears in the 
following table: 

Type Definition : - Data 1 : 1 : 

1 Tool changer l - automatic, tool 

number 

30 2 - retract 

3 - extend 

2 Coolant on/off 0 - off, 1 - on 

3 Enable servo 
power 
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B " n The Run messages are used with the StopRun 
messages to control the execution of synchronous 
Z fer The Run message asks the Logic Controller to 
start executing messages from its queue. 
Run <Qualifier> 
Run RunAttribute <attribute> 

The Run RunAttribute directs the Logic 
Controller to begin execution of the 
messages in the synchronous buffer. 

attribute> none 

Singlecycle The Run SingleCycle 
directs the Logic 
Controller to execute 
messages in the 
synchronous buffer a 
block at a time. Block 
are delimited by 
SingleCycleHeader 

messages . 

of messages from the synchronous buffer, it 
responds with a Running Message. If the Logic 
controller is not able to execute the messages^ 
from the synchronous buffer, it .responds with 

M «o The expected responses for 
NotRunning message. Tne expeu 

any of the Run messages are - 

Running <Qualifier> 

NotRunning <Qualifier> Description 

:errordescription> 

SSSBB Se StopRun message is sent to the Logic 
controller to halt the execution of the message « the 
synchronous buffer. The action can halt execute of 
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message immediately (with controlled deceleration of 
motion) or at a block boundary. Block boundaries are 
delimited by Cycle Headers. 

StopRun RunAttribute <attribute> 
5 This StopRun message asks the Logic 

Controller to stop execution of the 
synchronous buffer. It uses this format - 
StopRun RunAttribute <attribute> 

<attribute> immediate - deceleration 
0 motion at the maximum 

acceleration rate. 



•SingleCycle - stop 
execution at the first 
block end 

(singleCycleHeader) with 
15 out exceeding maximum 

acceleration. 

Expected Responses 

When the Logic Controller receives a StopRun 
message , it halts execution of the message in its 
20 synchronous buffer and responds with a 

StoppedRunning message. 

StoppedRunning <Qualifier> 

Wait 

A Wait message is usually sent to the Motion 
25 Controller in its synchronous queue. It asks the 

Motion Controller to not execute past this message 
until a StopWaiting message is sent. 
Wait Message 

Wait message <id> 
30 Expected Responses 

Waiting message <id> 
NotWait message <id> Description 
<errordescription> ... 
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Sample Messages 
Wait message 1152 

s£aeHai£ Messaqe ^ . . . . 

The StopWaiting message is sent to the 
Motion Controller to cancel a Wait message. 

StopWaiting message <id> 
Expected Responses 

StoppedWaiting message <id> 

Update messages are sent to the Logic Controller 
by Application program to provide information to the 
ladder program. The message may update a flag in the 
^fc controller data table, send a generic message, 
or provide a new ladder program to the Logic 

23 controller. 

Update <Qualifier> 
Expected Response 

The Logic Controller process Update 
m essages at the beginning of its scan. It 
responds with a Updated message to indicate 
20 tha t the update message was successfully 

executed. If the Logic Controller is not 
able to perform the Update, a NotUpdated 
Message is returned. 
, 5 updated <Qualifier> 

NotUpdated <Qualif ier> Description 



<errorDescription> 



30 



Flag Access Logic 

Controller data 
table by Names 

FlagID Access Logic 

Controller data 
table by flag id 



Generic Logic 
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Controller Message 



Program Loads sections of 
the Logic control 
message 

5 Update Flag 

The Update Flag message is used to change a value 
in the Logic Controller data table. These messages are 
interpreted at the beginning of each LC program scan. 
The Flag can be referenced through a Name or an ID. 
10 Update Flag Name <FlagName> DataType <Type> Value 

<FlagValue> 

Update Flag ID <FlagID>. DataType <Type> Value 
<FlagValue> 

Update LCmsg 

15 The Update LCmsg is used to send a 

generic message to the Logic Controller. 
The actual message is interpreted by the 
ladder program. 

Update LCmsg <msgTyP e> Size <MsgSize> 

20 Value <msg> 

Update Program 

An application uses the Update Program 
message to down load ladder program messages 
to the Logic Controller. The Program is down 

25 loaded by breaking it up into segments and 

* 

sending the segments to the Logic Controller. 
The 1 SequenceNumber 1 is used to make sure the 
program segments are received in order. 

Update Program ProgramID <ProgId> 
30 Sequence <SeqNumber> String 

<progSegment> 

Get 

An application sends a Get message to the Logic 
Controller when it wishes to access information from 
35 the Logic Controller's data table. 



WO 95/07504 




CT/US94/10029 



104 



Get Flag Name <FlagName> DataType <Type> 
Get Flag ID <FlagID> DataType <Type> 
Expected Response 

The Logic Controller responses to the 
Get messages at the end of each of the 
ladder program scans. The Got message 
is used to return the value of the 
requested flag. The NotGotten message 
indicates the requested flag was not 
10 defined. 

Got Flag ID <FlagID> DataType <Type> Value 

<FlagValue> 

NotGotten Flag ID <FlagID> DataType <Type> 
Description <errorDescription> 

15 T edder Lo gic Programming 

The ladder logic programming environment gives the 
OEM off-line tools and a controller resident monitor to 
customize the LC. There are three components of the 
ladder logic programming environment: 
20 Ladder Logic Programming Tool (off-line) 

Ladder Logic Debug Tool (remotely hosted, serially 

linked) . 

Logic Monitoring Tool (controller resident) 
The programming environment provides version control for 
25 the logic programs and back-up to any point in the 

changes. This feature also allows the OEM to branch off 
at a selected point and start new development paths for 
new machine strategies. 



30 



35 



Program™ i Bfl Tool 

An OEM can create and change ladder logic programs 

using familiar notation and concepts provided in the 
Ladder Logic Programming Tool. This tool gives the 
developer an easy-to-use off-line, graphical method for 
creating, editing, running, testing, and downloading logic 
control programs for the controller. With the tool the 
engineer can design control programs -from 'initial concept 
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to final operation using top-down design procedures. The 
following are programming tool's features: 

Supports programming in ladder logic: 
Coils and Contacts 
5 Virtual Coils and Contacts 

Timers 
Counters 
Branches 

Function Blocks for math (add, subtract, multiply, 

10 divide, trig.) 

Function Blocks for interface to CNC 
Output in •ANSI-C source code form for cross- 
compile to target coprocessor board 
Outputs a symbol table that may be read by other 

15 programs - useful for parameterization and 

creation of shared data tables 

Supports programming in sequential function charts 
(GRAFCET SFCs) 

Produces hard copies of program and data 
20 documentation 

Supports programming in timing diagram form 
Version control allows the integrator to make 
incremental changes with an audit trail 

Ladder Logic Debugging Tool 
25 The on-line debugging tool runs on a Windows 

workstation with a serial (RS2 32) link to the controller. 
This tool provides the following features: 

* Graphic illustration of the contacts and 
coils in the ladder program as they energize 

30 and de-energize 

* Ability to monitor and set values in the data 
table including counter and timer 
accumulators 

* Display of the GRAFCETsteps and transitions 
35 as they activate and deactivate 
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Ability to command the Logic controller 
engine to execute one scan at a time 

^ The real-time Logic Monitoring Tool gives the 
5 integrator a way to observe the states, inputs, and 
outputs of the machinery during cycling on the 
Tool itself. The software allows the integrator to watch 
for timing problems in I/O, facilities debugging of logic 
sequences, and helps with machine wiring or swrtch 

10 adjustments • 

The features of the Logic Monitoring Tool are 

listed below: 

* incorporated into, the CNC executive software 

system _ 
15 * Accessible though the CNC's platform 

diagnostic mode 

Displays states of inputs and outputs an 



real-time 

* 



Allows the integrator to force the states of 
outputs and view the responses of the inputs 
. Reads from an alias file to attach symbolic 
names to I/O point definitions on the screen 

mn» '-"l Hardware . 
The present invention System uses the aforementioned 

» MATRIX* multi-axis servo controller board. The system s 
approach to motion control maintains digital control 
throughout the position, velocity, and current loops as 
part of the CNC. As a result, the system achieves more 
precise, faster, and more robust closed loop control than 

30 other servo controls. Many control. functions. are xsolated 
in the motion control software. on the host computer This 
approach give the user more flexibility when responding to 
changing industry needs. ..This , also facilitates _ 
retrofitting a new CNC on existing machines.,, The MATRIX* 

35 controller board is a fully digital, 4-axis posrtxon and 
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velocity controller. The board provides constant velocity 
control as well as spindle orient capability. When coupled 
with the VECTOR4 daughter board, the system permits the 
CNC to control DC brush, DC brushless, and AC induction 
5 motors and permits most parameters to be programmed 
dynamically. Dynamic programming allows an engineer to 
update the motion control parameters immediately when 
there are changes in the environment or operating 
conditions. 

10 Motion Control Configurations 

Due to the system's configuration flexibility, OEMs can 
use machines with multiple motors. This is possible 
because the CNC hides the motors from the application 
software by sending CNC messages through the power modules 

15 to maneuver the motors. This structure allows easy 

swapping of motors without drastic changes in the machine 
design. 

For each controller board, an OEM can configure up to four 
axes with each axis independently supporting a different 
20 type of motor. Four boards can be used together to support 
up to 16 motors. The power modules between the CNC and the 
motors are inexpensive replacements for the proprietary 
drives common in many systems today. These modules can be 
purchased from many different suppliers. 

25 Motion Control Software 

The motion control software in the CNC translates part 
programming requests into basic position and velocity 
instructions. As shown in the illustration on the next 
page, the motion control software is divided into 

30 functional components. The operator uses the Part Program 
Interpreter (PPI) software to direct the motion of the 
axes. The PPI software may make use of pre-programmed, 
packaged cycles to perform common operations such as drill 
and tap. 
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Th e PPI sends requests to Process or Machine <*)«*•• . 
^'software loads the revests ana — o^er «- ; 
such as tooX change or coolant on/off , into 

™. T^.rface Driver software has these functions: 
T££ »d processes requests fro, shared memory 
. Interpolates motion lines 

. performs leadscrew mapping MATRIX4 board 

. Sends position/velocity targets to s 
The interface Driver can accommodate simultaneous 
from the host to multiple DSPs. The driver . 

onverts requests from the PPI into 
tar ,ets that are fed to MATRIX4 function 
interface. The driver also uses a C Horary 
prototypes to define commands for the MATRIX4 hoard. 

The -C library in the driver software defines the 

following: 
o Axis designators 
o Module designators 
o Multiple read parameter types 
20 o Disable interrupts masks 
•o servo modes of operation 
o Axes per module 

o Maximum number of axes per module 
o output loop gains 
25 o control Law indices 

o control PID gain indices 
o Error codes 

o Maximum and minimum velocities and accelerations 
o Block transfer rate codes 
30 o Function prototypes 

The motion control software also includes utilities to 
program the motor technology for the applicat^ These 
utilities permit engineers to configure, tune, and 
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maintain applications as well as document system 
performance. 

The MATRIX4 board accepts the motion commands and closes 
the servo control loop. Since axes move by having voltages 
5 applied to them, the MATRIX4 board converts the 

position/ velocity instructions into voltages (0 to 10 
volts) and applies the voltages to the axes being 
controlled. The MATRIX4 board does not need to understand 
the machine tool's operation since that function is 

10 handled by the software. 

Machine Configuration Library 

The Machine Configuration Library provides default 
parameters for applications in- a shared memory area. This 
service's responsibilities are to - 

15 * Load and distribute initialization parameters 

from the file system 

* Distribute parameters to applications 
In one embodiment, this parameter library uses a C++ 
object, SystemVariables, to read and write data in the 

20 globally accessible shared memory area. The library also 
contains utilities to create, load the configuration, 
print, list, save, restore, and remove the information in 
the SystemVariables memory region. 

The information in this section provides the 

25 details necessary for an engineer who wants to modify or 
develop new configuration programs. For more general 
information about these functions, refer to the 'Platform 
Services' discuss herein. 
Defining the Configuration File 

30 In development work for this platform service, the 

first step is definition of the configuration file 
containing the system parameters. An ASCII file may be 
used to define the shared variable name, its size, and 
each data field in* the shared memory. For example: 

35 - # This is an example configuration r ^ 

- ' # GT.- 11/19/92 - - — v:r - } - : 



WO 95/07504 




CTAJS94/10029 



110 



10 



15 



20 



25 



NAME /mnt/Bydirectory/sharedfilena^e 
SIZE 4096 



SOF 

# NAME 

kTermsX 

kTermsY 

kTermsZ 

kTenasS 

iTermsX 

iTermsY 

iTermsZ 

iTermsS 

vTermsX 

vTermsY 

vTernsZ 

vTermsS 

i_limit 

max_accel 

pwm_f req 

lines 

poles 

hall 

deadband 

loopType 

motorParam 

field 

motor 

TravelLimits 
Units 



TYPE 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
DOUBLE 
DOUBLE 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
INTEGER 
DOUBLE 
STRING 



COUNT 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 

4 . 
4 
4 
4 
4 
. 4 
.4 
,4 
4 

4 v 
4 

. 3 • 
1 



SIZE 



30 



35 



rae «rst two lines for the syste.Va.ia.Xes configurate 
are counts heoinnind with the sign- 

keywords »ust he ^ ^^0^ - ^ of 
second Une uses the »M E *eyw ^ ^ ^ M 

the systemvanables fUe- » ■ o£ . the data area 

used. The third line species W> - 

U sin 9 the sm ^-; h : a :r sp a=e sef ds less than 
4K increments, even if the data space us 



WO 95/07504 M ■vuS94/10029 



111 

that. The SOF (start of fields) keyword must precede the 
defined fields. 

The six supported field types are byte, string, 
double, integer, short integer, and long integer. The 
5 first column identifies the name of the field. Field 

names are limited to 30 characters plus a null terminator 
making it a total of 31 characters. The second column 
defines the field type, string, double and integer. There 
is no limit to the length of a string. The third column 

10 defines the number of elements to be stored for that field 
name. The example shows the field 'kTermsX' to contain 4 
integers, 'TravelLimits • 3 doubles and 'Units' l string 
containing 7 characters (including any null terminator). 

At this time, the SIZE -field is used only for the ' 

15 string data type. It indicates the length of the string 
(including null terminator) . 
Utilities 

After creating a configuration file, the engineer 
needs to set up the memory area and load the configuration 
20 parameters. The library contains utilities to create the 
shared memory area, load the configuration, print, list, 
save, restore, and remove the information in the 
SystemVariables memory region. These utilities are - 

SVsize 
25 SVcreate 

SVprint 

SVloadConf ig 

SVlistData 

SVsave 
30 SVrestore 

SVremove 

SVshmdump 

These utilities are described in the order they are most 
commonly used beginning with the SVsize utility. 
35 SVsize 

The first utility an engineer may need, SVsize, 
establishes the size of the shared memory. :; in ttie 
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example below the 40.. « rr ^^.^ • 
for the defined shared data area. ^ 
parameter indicates the total amount of space r q 
for the shared data definition that the -gxneer 

nLd This figure must be increased up to the 
5 specified. This fig parame ter in the 

next 4K value and used as the sut P 
configuration file. 
Sizing 

t/mnt/mydirectory/sharedfilename] 
L0 " size Indicated [4096] 

Header [ 12 3 

Table C 110 °} 

Data t 431 3 

Total Bytes Used [1.543] 
15 Available Bytes [2553] 

Size Completed. 

^^ter defining the shared data area, the engineer 
may create the shared data area us in, the SVcreate 
utility. Below is an example using thrs utility 

'"funding. . [ /»nt/„ydirectory/sharedmena„e ) 
Size [4096] 

Shmid [/mnt/mydirectory/sharedfilename] 

25 created. 

kTermsX 

kTermsY 

kTermsZ 

kTermsS 

30 iTermsX 

iTermsY 

iTennsZ 

iTermsS 

vTenasX . 
35 vTermsY 

vTermsZ . 

yTermsS vr/ /:.; -.xn 



20 
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i_limit 
max_accel 
pwm_freq 
lines 

5 poles 
hall 

deadband 
loopType 
motorParam 
10 field 
motor 

TravelLimits 
Units 

Bytes Used [1543] , 

15 Available Bytes. [2553] 

Build Completed. 
SVprint 

Once the shared data area has been created, the 
engineer may display the data description using the 
20 SVprint utility. The SVprint utility displays the 

field name, data type (B, I, D, S, H, L) the count 
(number of elements) and the size of each String field. 
Below is an example showing integer (I) , double (D) and 
string (S) data types. This utility also. shows the 
25 size of each string field. 

NAME [ /mnt /mydirectory / sharedf ilename ] 

SIZE [4096] 

Name Type Count Size 



30 



35 



TravelLimits 


D 


3 


Units 


S 


1 


deadband 


I 


4 


field 


I 


4 


hall 


I 


4 


iTermsS 


I 


4 


iTennsX 


I 


4 


iTermsY 


I 


4 



WO 95/07504 



CTA3S94/10029 



10 



15 



20 







114 


iTermsZ 


I 


A 
4 


i_limit 


D 


A 

4 


kTermsS 


I 


A 

4 


kTermsX 


I 


A 


kTermsY 


I 


A 

4 


kTermsZ 


I 


4 


lines 


• I 


4 


loopTyp 


I 


A 
4 


max_accel 


D 


4 


motor 


I 


4 


motorParam 


I 


4 


poles 


I 


4 


pwm_freq 


I 


4 


vTermsS 


I 


4 . 


vTermsX 


I 


4 


vTermsY 


I 


4 


vTermsZ 


I 


4 


cvi n^dConf iq 
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Next the engineer may 

shared »e*ory using the SVloadConfig utxlity. This 
Utility uses an ASCII file descrihing the va ues 
assigned to each field. The format of the file 
follows: 

# These are the default values used for 
SharedVariable example programs 



30 



35 



# FieldName 
kTermsX 
kTermsX 
kTermsX 
kTermsX 

# 

kTermsY 
kTermsY 
kTermsY 
kTermsY 

# 

kTermsZ 



Index 
o 
l 
2 
3 

0 
1 
2 
3 



Value 



7000 
. 30000 
12000 
19400 

0 

20000 

5000 

7000 

2000 
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kTermsZ 
kTermsZ 
kTermsZ 
# 

kTermsS 
kTermsS 
kTermsS 
kTermsS 
# 

iTermsX 
iTermsX 
iTermsX 
iTermsX 
# 

iTennsY 
iTermsY 
iTermsY 
iTermsY 
# 

Units 



1 
2 
3 

0 
1 
2 
3 

0 
1 
2 
3 

0 
1 
2 
3 



18000 

3000 

5350 

7000 
30000 
12000 
19400 

0 

15000 

4000 

0 

0 

28000 
15000 
0 



Metric 
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In the SVloadConfig utility, lines beginning with a # 
sign are interpreted as a comment. The first column 
specifies the field name while the second column is the 
index. The fields or indexes do not have to be defined 
in any specific order. The third column is the value. 
If a field cannot be found or a value is invalid, an 
error message is printed. 
SVlistData 

The engineer may list all the data values that are 
currently stored in the shared area using the 
SVlistData utility. This utility outputs a file that 
can be read using the SVloadConfig utility. The value 
for each field by index is printed. 
SVsave 

After modifying the data stored in the shared 
area, an engineer may want to save the information to 
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disk. This can be done using the SVsave utility. 
Below is an example using this utility. 

NAME [/nnt/mydirectory/sharedfilename] 

SIZE [4096] 

Save Completed 
The save utility saves the shared area under the 
filename specified in the configuration file with a 
.sav extension. 
svrestore 

To restore a previously saved file, use the 
svrestore utility. Below is an example using this 



utility: 

NAME [/mnt/mydirectory/sharedfilename] 

SIZE [4096] 

!5 Restore Completed 

svshmdump 

There is another utility, SVshmdump, that may be 
of interest for debugging the shared area at a very low 
level. This program dumps the shared area in hex bytes 
20 and is useful when the engineer wants to inspect the 

shared area. 

sharsd Memory Orga nization 

The SystemVariables area can be described as a 
contiguous area of shared memory. This memory is divided 
25 into three sections: 

Shared Memory Storage Header 
Table of Contents 
Data Storage 

The header is divided into three fields: 

Number of fields defined in the shared area 

(first 4 bytes) 

Offset into the shared area (used when -, : 

allocating space for new fields) 

An integer storing the semaphore handle (used 
to synchronize access to the data, area only) 
The header structure is as follows: 



35 
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typedef header { 
int number_of _f ields ; 

long of f set_into_datastorage; 

int semaphore; 
5 } header ; 

The second four bytes of the header contain a 
. long integer (also four bytes) of the offset 
into the shared area. This value is used 
when allocating space for new fields in the 
10 shared area. In this scheme the table of 

contents (the field descriptions) grow 
downward while the data storage area grows 
upward. Finally, the header information 
contains an integer storing the semaphore 
15 handle used to synchronize access to the data 

area only. This means the semaphore is not 
used when getting information about the 
fields, but only for reading and writing into 
the data area. 

20 Note: The byte sizes described in this 

document for integer and double reflect those 
of a 38 6 and 486 architecture. 
The second section of the shared area is the table of 
contents. This area contains a series of field 
25 descriptions each can be described using this data 

structure: 

#define FIELD_NAME_LENGTH 31 
typedef struct f ield_description 

{ 

30 char fieldname [FIELD_NAME_LENGTH] ; 

char type; 

unsigned int count; 
unsigned int size; 
unsigned int offset; 
35 } f ield_description; 



WO 95/07504 



T/US94/10029 



118 

The first 31 bytes of each field description contains 
the field name. This is the same name that is used in 
the configuration file. At this time an upward limit 
of 31 characters (including Null terminator) is 
5 allowed. The next byte in the description indicates 
the field data type. The six field data types are 
represented by these letters: 

B - byte 

I - integer 
10 D - double 

S - string 

H - short integer 

L - long integer 

» 

The next four bytes describe an integer representing 
15 the number of elements to be stored under this name. 

This can be. considered an index into an array beginning 
with the index zero for the first element. An integer 
representing the size of each element is stored after 
the count. Doubles use eight bytes and integers four, 
20 with user defined the string sizes. The final four 

bytes of the field description contains the offset from 
the beginning of the shared area into the data storage 
area where the stored values are kept for the field. 
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Writing a Program 

An engineer wishing to write a program to access 
the shared memory area may. want to examine the following 
example. This program, simply creates a SystemVariables 
object, passing the configuration filename to the object. 
Calls are made to the SystemVariables object for getting 
the size, mapping the fields to field objects, getting and 
updating data, and other necessary actions. >. 
#include <stream.h> 
#include ••SystemVariables.hpp" 
main (int argc, char *argv[]) ; . ■• . , -. 



35 { 
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int error ; 

double doubleValue; 

if (argc < 2) 

{ 

5 cout « form ("Usage: %s conf iguration- 

filename\n", argv[0] ) ;exit (-1) ; 

} 

/* Instantiate a SystemVariables object, 
specifying the configuration file name to be used 
10 */ 

SystemVariables SystemVariables (argv[l] , error); 
/* Check the error code returned from the 
constructor call */ 
if (error) 
15 { 

perror ("SystemVariables Constructor"); 
exit (-1) ; 

} 

/* The Size method call is one of many calls 
20 that will return information about the shared area 

*/ 

if (SystemVariables. Size () == 0) 
{ 

perror ("Invalid size"); 
25 exit (-1) ; 

} 

/* 

Here is a simple call to get the value stored in 
the 0th index of the field called "max_accel". 
30 */ 

error = SystemVariables. Get ("max_accel" , 
doubleValue, 0) ; 

cout « form ("max_accel value 
[%f] \n", doubleValue) ; 
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Finally, close the connection to the shared 

data area. 

*/ 

if ((error = systemVariables. Close () ) ) 

{ perror ("Cannot close shared area!"); 
} 

} 

10 Below is the maKe file used to compile and link this 

program: 

CFLAGS=-X -i/usr/local/include 

OB J= • / 
EXE=../ 

15 LIB=/usr/local/lib/ 

OFILES= $ (OBJ) example. o 
$ (EXE) example: $(OFILES) 

g++ -X $ (OBJ) example. o $ (LIB) libSV. a-o 

$ (EXE) example 

20 $ (OBJ) example. o : example. cc 

g++ - c $(CFLAGS) example. cc -o 

$ (OBJ) example. o ■Followina 
The SystemVariables Methods are described in the following 

section- 

The Machine Configuration Library uses an j . 
such as a C~ object, SystemVariables, to read and write 
data in the globally accessible shared memory area^ The 
SystemVariables methods are defined below and the possible 
30 return values are listed for each method. 

BM ^is Class method returns the base pointer to the 
. shared area. The function prototype for this method is 
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char *BasePtr ( ) 

Return Values: 

A non Null pointer on success. 

Close 

5 This class method closes a connection to the 

shared area. The function prototype for this method is 

int Close ( ) 

Return Values: 
10 0 Success 

-1 - Error. Check 'Errno 1 for a 
description of the error. 

An error may occur during an unmap call of the shared 
area or a close call to the. shared area file. Errno is 
15 set when these errors occur. 
Description 

This class method returns a character string 
describing the field. The string contains the field 
name, type, count and size (in case of string types) . 

20 The calling program must perform a delete on the 

returned description. The application may use the 
Field or GetField method calls to obtain the Field 
parameter used in this call. The function prototype 
for this method is - 

25 int Description (svField fcfield, char 

description) 

See Also: GetField, Field 

Field 

This method finds the Field for the field 
30 specified by fieldName. The function prototype for 
this method is - 

int Field (char. *fieldName, svField fcfield) 
Return Values: 
0 - Success 
35 -2 Cannot find field. 

-3 - Shared Area Not Initialized. 
See Also: Get, Update. 
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yjgldCount 

This method gets the number of elements for the 
field specified by fieldName. The oount is returned in 
tne parameter oount. The function prototype for this 

method is - 

int FieldCount (char *fieldName, int &count) 

Return Values: 
0 - Success 
-2 - Cannot find field. 
-3 - Shared Area Not Initialized. 

This method gets the size of the field specif led 
by fieldName. The size is returned in the parameter 
size. The function prototype for this method is - 
int FieldSize (char *fieldName, int isize) 
Return Values: 
0 - Success 
-2 - Cannot find field. 
-3 - Shared Area Not Initialized. 

20 F;igldTvr>e 

This method gets the data type for the field 
specified by fieldName. The type returned in the 
parameter, type is I for integer, D for double S for 
string, B for byte, H for short integer, and L for long 
25 integer. The function prototype for this method is - 
int FieldType (char *fieldName, char type) 
Return Values: 
0 - Success 
-2 - Cannot find field. 
-3 - shared Area- Not Initialized. 
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T fileName 

This class method returns the configuration 
filename used to define the shared, data area. The 
function prototype for this method is - 
35 char *FileName( ) 
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This method retrieves the value stored for a given 
field by name. 

int Get (char *fieldName, int &data, int index) 
int Get (char *fieldName, char *data, int index) 
5 int Get (char *fieldName, double &data, int index) 

The index parameter is optional. If it is 
not used, the Oth index is searched. Care 
must be taken when getting string values. 
The engineer must make sure the character 

10 pointer that is passed into this method has 

» 

allocated enough space to store the character 
string. A good way to do this is to use the 
FieldSize method to get the size of the 
character string. • Then allocate the space 
15 before calling this method. 

Return Values: 

0 - Success, 
-1 - Invalid field type. 
-2 - Field not found. 
20 -3 - Shared Area Not Initialized. 

-4 - Invalid Index. 
The Get method also retrieves the value stored for a 
given field as specified by the sf Field reference. 

int Get (sf Field Sfield, int &data, int index) 
25 int Get (sfField &field, char *data, int index) 

int Get (sfField &field, double Sdata, int index) 
The Field pointer is found using the Field or 
GetField methods. The engineer must make 
sure the character pointer that is passed 
30 into this method has allocated enough space 

to store the character string. A good way to 
do this is to use the FieldSize method to get 
the ? size of the character string. Then 
allocate the space before calling this 
35 method. 

Return Values: 
0 - Success, 
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-1 - Invalid field type. 

-3 - Shared Area Not Initialized. 

-4 - Invalid Index 

See Also: Field, GetField, 

5 FieldSize. 

ftetField 

This method call is used to traverse the list of fields 
in the shared area. By using a zero in the parameter 
data you will begin at the top of the list. After each 
10 call the data parameter will be incremented. The list 
can be traversed by calling this method successively 
until a return value of -1 is return. The function 
prototype for this method is - 

int GetField (svField &field, int fcdata) 
15 Return Values: 

0 - Success 
-l - End of list, 
-3 - Shared Area Not Initialized. 
See Also: Get, Update. 

20 Name 

This class method returns the shared area name 
specified in the configuration file. The function 
prototype for this method is- 
char *Name ( ) 
25 NumberOf Fields . 

This class method returns the number of fields defined 
for the SystemVariables . The function prototype for 

this method is- 

int NumberOfFields ( ) 

30 Remove 

This class method will remove the shared area 
completely. After this call no other applications will 
be able to access the shared area. The function 
prototype for this method is- 
35 int Remove ( ) 

Return Values: 
0 - Success 
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-1 - Error occurred during an unmap call or 
close call to the shared area file. 
Check errno for a description of the 
error . 

5 -3 Shared Area Not Initialized. 

-4 - Cannot unlink the shared area file, 
-5 - Cannot unlink the shared area 

semaphore . 
Save 

10 This class method will save a copy of the shared area 

to disk. The file name will use the shared memory name 
with a suffix of save. The function prototype for this 
method is- 

int Save ( ) 
15 Return Values: 

0 - Success 
-1 - Cannot open the save file. 
-3 - Shared Area Not Initialized. 
Refer to the description of the 
20 'Restore 1 method for more information. 

. Restore 

This method will restore a saved copy of the shared 
area. When using the Save and Restore methods a 
filename with the .sav extension is used. The function 
25 prototype for this method is- 

int Restore ( ) 

Return Values: 
0 - Success 
-1 - Cannot open the restore file. 
30 -3 Shared Area Not Initialized. 

The Save and Restore methods use the 
shared area name with a .sav extension 
appended to it as a filename for saving 
and restoring a shared area. The file 
35 is saved in a binary format and can only 

be read using the Restore call. Use the 
SVlistData utility program to create an 
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ASCII readable file of the current field _ 
values. 

S class method returns the total size in bytes of 
5 the shared area (not the amount of shared area bexng 
used) . The function prototype for this method is- 
int Size( ) 

Sedate method replaces the value stored for a given 
10 field with the value given in data. 

int Update (char *fieldName, int data, int xndex) 
int Update (char *fieldName, char *data, int xndex) 
int Update (char *fieldName, double data, int xndex) 
the index parameter is optional. If it is 
not specified the Oth index is used. When 
updating a string field type the field sxze 
will limit the number of characters stored. 
For example, if you have a character string 
of thirty characters and you update a fxeld 
that can only hold twenty, only the first 
twenty characters will be stored. 
Return Values: 

0 - Success , 
-1 - invalid field type. 
-2 - Field not found. 
_3 - Shared Area Not initialized. 
-4 - invalid Index 
The Update method also replaces the value stored for a 
given field as specified by the sfField reference, 
int Update (sfField &field, int data, int xndex) 
int Update (sfField (fitld, char *data, int xndex) 
int Update (sfField fifield, double data, int xndex) 
The Field pointer. can be found using the Field or GetFxeld 

methods. 
35 Return Values: 

.0 - Success,. • 
-1 ... -. Invalid. field type. : 
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-3 - Shared Area Not Initialized. 
-4 - Invalid Index 

See Also: Get, Field. GetField. 

Semaphore 

5 This method returns the semaphore handle used to 

synchronize access to the shared area. The function 
prototype for this method is- 

int Semaphore ( ) 
PostSemaphore 

10 This method call will release the semaphore used to 
synchronize access to the shared area. You must use 
the WaitSemaphore method call to get the semaphore 
before calling this method. The function prototype for 
this method is - 

15 void PostSemaphore ( ) 

WaitSemaphore 

This method call will get the semaphore used to 
synchronize access to the shared area. The call will 
pend until it can get the semaphore. The function 

20 prototype for this method is - 
void WaitSemaphore ( ) 
The WaitSemaphore and PostSemaphore calls are used to 
allow a program to get access to the shared area and 
make several calls without the overhead of getting and 

25 releasing the semaphore with each get/update call. 
This call should be used in conjunction with the 
PostSemaphore method call. In some cases an 
application may want to update or get data for a group 
of fields without having to get the semaphore for each 

30 call. ' 

In this case the application would make a call to 
WaitSemaphore, then update/get data for all the fields 
followed by a PostSemaphore call. Care must be taken 
when performing this call so as not to hold up other 

35 processes for too long a period. This method will save 
35 microseconds from each get/update call. 
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SVfjgld Methods • 

The SystemVariables class uses an SVfield class to 
describe each field within the SystemVariables. To get a 
reference to individual fields, use the GetField or Field 
method calls in the SystemVariables class. By getting an 
SVfield reference, the engineer greatly improves the 
efficiency of accessing fields in the SystemVariables 
because this eliminates the search for the individual 
field, in addition, this provides information about 
individual fields by making calls to the SVfield class 
methods. This section describes the SVfield class method 

calls. 
Name 

This class method returns the name of the Field. 
Field names are currently limited to 31 characters 
including the Null terminator. The function prototype 
for this method is- 
char *Name ( ) 

Type 

This class method returns the field data type. 
The return value may be I (integer), D (double), S 
(string), B (byte), H (short integer), or L (long 
integer) . The function prototype for this method is- 
char Type ( ) 

25 Count 

This class method returns the number of elements 
that may be stored under this field name. Elements. are 
numbered beginning with 0. For example, an integer 
field with a count of five may be accessed using an 
30 index from 0 to 4 . The function prototype for this 
method is- 

int Count ( ) 
Size • ■ ■ 

This class method returns the size of each field 
element. . Under the Lynx OS (for 386/486 systems) 
integers and doubles are stored in four bytes, strings 
are stored by any size. For example, a string field 
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with a count of seven and a size of ten means there are 
seven character strings of length ten (including the 
Null terminator) . The function prototype for this 
method is- 
5 int Size ( ) 

Exception Reporter 

The error codes used to filter error messages are 
available in the file • ErrorCodes . hpp . ' This file may be 
modified and expanded to meet the customer's needs. 
#ifndef _ERRORCODESHPP 
#define _ERRORC0DESHPP 
# 

# FileName: ErrorCodes . hpp 
* 

# $Header$ 

# $Log$ 
# 

static char *ERRORCODESHPPRC string = "$Header$ M ; 

typedef enum ExceptionSeverityValues 
{ 

NO_SEVERITY = 0x0000, 
INFORMATION - 0x0001, 
WARNING = 0X0002, 
FATAL = 0x0004, 

A11_SEVERITIES = 0x0007, 
} ExceptionSeverityValues; 

typedef enum ExceptionCategoryValues 
{ 

NO_CATEGORY ■ 0x0000, 
30 MOTION = 0X0001, 

LOGIC_CONTROL = 0x0002, 
DEVI CE_LAYER = 0x0004, 
DIRECTORY SERVICE = 0x0008, 
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RFSERVED 10 = 


0x0010, 


RESERVED 20 = 


0x0020, 


RESERVED 40 = 


0x0040, 


PEcjfRVED 80 — 


0x0080, 


nc;FR DEFINED 01 


= 0X0100, 


USER DEFINED 02 


= 0X0200, 


USER DEFINED_04 


=0X0400/ 


USER_DEFINED_08 


= 0X0800, 


USER_DEFINED_10 


= oxiooo, 


USERJDEFINED_2 0 


= 0X2000, 


USER_DEFINED_40 


= 0X4000, 


USER_DEFINED_80 


= 0X8000, 


ALL_CATEGORIES « 


OxFFFF, 


} ExceptionCategoryValu.es ; 



15 typedef enum ErrorCodes 

{ 

EX_NO_ERROR, 

EX_NOT_FOUND, 
EX_REPLACE_ME_0 0 1 , 
2 o EX_REPLACE_ME_0 0 2 , 

EX_REPLACE_ME_0 0 3 , 
EX_REPLACE_ME_0 04, 

} 

Manhine Class 
25 Creating a New Machine Class 

Creating a completely new Machine Class is a more 
complex process than simply modifying an existing Machine 
Class. A customer may create a new Machine Class for one 
of the following reasons: 
30 * Existing Machine Classes do not contain the 

objects needed to operate the customer's extremely 
specialized machine 
* The customer wants to replace the messaging 

interface. 
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* The customer has a specialized Kernel and needs to 
develop a Machine Class to communicate with it. 
As with all development efforts there are two main stages: 
preparation and development. 

5 Preparation 

To prepare for development of a completely new 
Machine Class, the customer should analyze the target 
machine tool to identify all of its devices. 

The customer must also identify the system tools 
10 to assist in this effort. Some of these tools are - 
OS utilities 
ANSI C compiler 

C++ programming features (compiler, inheritance of 
object characteristics, and isolation of 
15 changes) 

UNIX-based development tools 
The customer needs to become familiar with two important 
control system components: 

* Well-documented Kernel interface including message 
20 parameters and Logic Controller flags (in this 

manual) 

* Full source code for the sample, generic Machine 
Class 

An understanding of these two components simplifies the 
25 development effort by helping the customer to connect the 
new Machine Class to existing Kernel functions. 

Development Steps 

The steps a developer should follow when creating 
a new Machine Class are as follows: 
30 1. After a thorough analysis of the target machine, 

name all of the devices needed to operate the 

machine. These become the new Machine Class 

objects. 

2. Identify all of the methods used by each device. 
35 It is often helpful to use the same verbs as those 
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In tt.iz 



used by existing Machine Class objects, 
way, the developer can connect and use the 
existing messages. 
3. Match the available Kernel functions to the ne. 
«achine class objects. Create new aessages 

needed. M „ v 
Those of skill in the art will appreciate that »an, 
variations to the invention as described hereby be 
Ma e without departing fron the spirit and scope of t_ 
invention, and such variations are with scope of the -elow 
claims. 
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CLAIMS 

1. A machine tool control system for a machine tool 
of the type comprising a controllable/ movable tool for 
shaping a workpiece, means for receiving control 

5 instructions describing shaping functions to be performed 
on the workpiece, a processing unit and memory means, said 
control system comprising means for receiving and storing 
in memory means workpiece shaping instructions; means for 
transmitting command signals to a movable tool to thereby 

10 cause the tool to move; characterized by an object 
oriented software program comprising a plurality of 
transmitting objects, a plurality of receiving objects, a 
plurality of messages wherein the plurality of messages 
are transmitted to the plurality of receiving objects by 

15 the transmitting objects, and a motion controller software 
module for receiving messages from at least one of the 
plurality objects, the received messages including 
commands indicating desired movements of a movable tool, 
the motion controller software module further comprising 

20 means for sending command signals to the transmitting 
means to thereby cause the movable tool to move. 

2. The machine tool of Claim 1 characterized in 
that at least one of said objects comprises a model of a 
shaping process to be performed on a workpiece by the 

25 movable tool. 

3. The machine tool of Claim 2 characterized in 
that at least one of the objects comprises a model of a 
movable tool for shaping a workpiece, and the movable tool 
object exchanges messages with the shaping process object. 

30 4. The machine tool of Claim 1 characterized by 

first and second objects each comprising a model of a 
shaping process to be performed on a workpiece, and the 
model of the second object is inherited from the first 
object. 

35 5. The machine tool of Claim 1 characterized in 

that at least one of said objects comprises a model of a 
hole-making capable of forming a hole in a workpiece, the 
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model including definitions of the X, Y and Z dimensions _ 
of the hole. 

6. The machine tool of Claim 1 characterized in 
that at least one of said objects comprises a model of a 

5 milling process capable of being formed in a workpiece, 
the model including a two-dimensional definition of a 
shape . 

7. The machine tool of Claim 1 characterized in 
that at least one of said objects comprises a model of a 

10 contouring process capable of being performed on a 
workpiece being turned in a lathe. 

8. The machine tool of Claim 1 characterized in 
that the objects include status means representative of 
whether the process defined by the object has been 

15 performed on a workpiece. 

9. The machine tool of Claim 1 characterized in 
that at least one of the objects comprises a model of a 
movable tool for use in connection with shaping a 
workpiece . 

10. The machine tool of Claim 1 characterized by 
means for receiving from movable tools signals indicating 
faults with a movable tool, and a device fault software 
module comprising means for storing information regarding 
detected faults from movable tools, means for storing, for 
each detected fault, a sublist of the objects to which to 
send an object oriented message identifying the detected 
fault, and means for sending, upon receiving information 
regarding a movable tool fault, an 'object oriented, message 
to each object associated with the fault. 
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